Hi guys!
We're moving from NXP's LPC175x MCU to LPC18xx MCU. On LPC175x we use both CAN controllers making some kind of gateway between 2 CAN networks. The logic is quite simply, any frame coming from CAN0 network is transferred to CAN1 network and any frame coming from CAN1 network goes to CAN0 network. The setup is quite simple too, all IDs are accepted on both controllers (acceptance filters are not used). LPC175x devices have triple CAN Tx buffer on each controller so everything works just fine even at high network loads.
Now it appears that on LPC18xx series the CAN controllers are quite different, they gone for "message-objects" setup with message memory map. So we're trying to learn how to use them in our application. And we kinda stuck now. We got the CMSIS based CAN example coming for MCB1800 Keil board, using Keil v5 environment. Got rid of real time OS and moved few things around the CMSIS driver.
The idea is to create a RX message object using ObjectSetFilter(1, ARM_CAN_FILTER_ID_MASKABLE_ADD, ARM_CAN_STANDARD_ID(0x1FFU), 0U); We're supposing this will cover all 11bits frame IDs. And it looks like we're able to receive all ID from 1 to 1FF.
Then we're trying to recreate our triple Tx buffer by allocating 3 Tx message-objects for this purpose. Then the logic is simple, getting Rx interrupt coming from CAN0 Rx message-object, picking up frame data, setting up Rx flag to indicate the new data available then in the main loop transmit the data through CAN1 controller. Same for CAN1 controller, get the data and send all through CAN0. Main loop is just a while(1){ read the flag / send the message } for test purposes.
All this seems to work but we have some important frame loss somewhere in between. This never happened with LPC175x series MCUs. And honestly, we cannot believe that the LPC18xx with double operating clock frequency cannot move frames between both controllers fast enough! Something is definitely wrong with our approach and all this message-object setup. We're thinking the single Rx message object could be the reason but no idea how to create multiple ones with same mask. Would you, please, suggest the direction to dig?
Thanks all!
Hi Dimitri.
I think with repeated IDs you are actually having a problem with reception happening while you are starting a transmission.
I think you will have to either use FIFO or use a message queue (or some other array) for buffering received messages.
If you can receive all messages when you are only testing the reception then you have to ensure they are buffered before you try to send them otherwise some overwrite will happen as it seems is happening in your case.
I don't think this is a hardware issue.
It looks like at some point there are very short times between two messages thus new message is received before previous wan was loaded for transmission thus new data was read from new received message and then loading for transmission continues with now changed data.
About the extended frame, as you can see in the piece of code you posted it seems that bit 30 is a flag specifying the extended frame, because you need a way to differentiate standard IDs and extended IDs.
To specify extended frame your ID should have bit 30 set to 1.
Your ID 0x100A00 would be specified as 0x40100A00.
Best regards, Milorad
Hi Milorad!
I couldn't stop thinking about how both specific IDs were affected. I can understand the eventual timing issue between Tx and Rx but why only these 2 and only on CAN2? So today I ran the same load test on out previous LPC1756 hardware. Guess what? Got the same result after 100K+ frames. Different hardware, different CAN driver architecture but same canalyzer. So I put the logic probes on both CAN channels to see what exactly is going on.
Here it is, the bottom is CAN2 the top is CAN1 (btw, do you see how ridiculously small is the timing between frames?)
As you can see, at the moment when canalyzer sends 0x0C2 from CAN2 channel, it also sends the 0x0E1 from CAN1 channel. And somehow the data is mixed, the CAN1 frame data goes to CAN2 frame data. We use a quite expensive muti-protocol tool and this is clearly a bug on their side, nothing to do with us. Same is happening to those extra IDs, this time the tool messes with ID only, I can see them physically present on the CAN bus. Once more, nothing related to CAN driver.
So my guess this is it, all works as expected.
Look, without breaking the privacy policies I'd like to reach you to express our gratitude. Without your help and your knowledge, this project would take awhile to achieve, non-working CAN was the blocking issue. Thank you very much!
Dimitri
The space between frames is so called 'interframe space' and it needs to be minimum 3 bits long, so, yes, very short space between.
I'm very happy you managed to solve the problem, and that I was able to help.
Don't worry about expressing your gratitude, a simple thank you is just fine :-)