Tx MB, baudrate and bus loading is included in errata description since it's very hard to reproduce it. If you force a low baudrate with a high bus loading, two or more MBs receiving and try to Tx, you will see after a while, even if these factors are not necessary to show bug.
Errata was shown with a 5282lite board and CANalizyer running a script.
Have fun!
Hello Paolo:
THanks for your reply. Yea, seems like low baudrate may catch it under heavy loading conditions. I will go down a few kbps and see if I see the error. However the root cause of this problem remains unclear. Even if the errata is caught, it would be nice to understand the root cause, so that a mitigation plan can be developed.In other words, a safe alternative can be developed to avoid pushing freescale into that state.
The errata says, when one rx mailbox gets locked, then both smb's get full, and when mailbox get released, smbs force message into the incorrect mailbox resulting in a corruption.THe latest errata asks the customers not to use all bit masks for Rx ( and does not talk about tx'ing.) If we infact change our bit masks, will it be assured that Tx would not cause any issue???
Thanks in advance.
san.
Latest errata (SECF125) talks about do not using ID bits 14 to 0 for extended ID's.
Prior FlexCAN Errata (SECF123) about writing to a receive MB may corrupt MB content.
Regarding SECF123:
- Please follow both workarounds to get rid off this
- Errata will happen with 2 or more Rx MB. If you only use a single Rx MB errata will never happen. (Safest alternative)
As I said, Tx MB, Baudrate and bus loading are not part of errata, but are needed to force this condition and see the bug. Some customers have been using this uC for a while and have never seen the errata. So if you follow workarounds you won't see errata.
Hope this clarifies things
Hello Paolo:
Thanks for the clarification. Well, yea, i do agree to what you said. catching the bug is one thing and coming up with a safe alternative is another. Using a single mailbox sounds like the only alternative to the problem. In other words, I can only have one Rx mailbox for all CAN communications. However my only concern is, what is the single mailbox gets corrupted?? .. and i lose each and every message , forever until a POR. Can i be assured that the errata will not show again? with 100% confidence.
Thanks you once again for your continued support on this issue.
san.
Hello pas/Charlie2:
I am trying to catch the errata , but was wondering if I can get the bus loading conditions, ( transmission rate, receive rate, .??) Have you seen this happening just with the Rx traffic or a simultaneous( async). rx/tx traffic..
-ss
Hello Charlie:
Thanks for getting back .I am writing an app that would catch this specific errata, but seems like I never catch this. I am not changing the existing driver, as I know doing this might catch the errata faster. Now, say if App 1 catches the errata, then I would then play around with driver and come up with another driver 2 that would essentially not let freescale get into the errata state, and then try app 1 with the changed driver and see how the behaviour is.The goal being that driver 2'fixes' the errata for my application.
Thus its getting tricker to catch the errata as I am trying to come up with a suitable application, without changing the existing driver file. ALso, I am not trying to a Tx inside the isr/driver and this means, the process to do a Tx/Rx is getting tougher.
Any ideas or help would be appretiated. Thanks in advance.
san
HEllo pas:
THe errata issued by freescale talks ONLY about Rx processes. However, this thread started off with doing a Tx/Rx simultaneously to catch the errata. Not sure why Freescale is hesitant to add Tx inforamtion into their Errata... Any ideas?
Thanks in advance.
san.
San,
Hard to say as I don't know the details of your driver or app. Do you have a CAN bus analyzer? In my case, both devices transmitted asynchronously and we could monitor the activity on an analyzer. As the tx and rx windows moved within a message length amount of time, the error would occur.
FYI, the new errata was just published on the Freescale site 5/5/09.
Charlie
Hello :
After a 'slightly longer than expected' work,I was able to come up with an application without changing the driver for coldfire.
The observation I made was that as long as a few nibbles ( higher) in message ID used for hardware filtering match up, we should see the errata irrespective of the interested node doing a tx/Rx. I was able to see the mailboxes filters getting corrupted again and again indefnitely to accept a different message. The rate at which this happens is also the rate at which messages are received by a coldfire node.
ex: if mailbox 1,2,3 are configured to accept msg 1 msg 2 msg 3, during startup, sometimes, mailbox 1 gets corrupted to accept msg 2, after a while mailbox 2 could get corrupted to accept msg 1, sometimes all three mailboxes get corrupted to accept ONLy msg 1, and so on. I was able to accelerate this if I had a faster Tx rate of the messages coming from a different node ( A can analyzer etc.
This blog helped me in understanding the errata and if anyone wants an application , i can defnly send a pseudocode or may be the code that does exactly that.
san.
Hi all
As an additional comment:
- RX MBs corrupted wont NEVER happen if a single MB for Rx is used.
- To get rid of the second errata (extended IDs), use a software filtering (do not use general ID mask nor particular MB mask) using a single RX MB. Even if the rest of MBs are used for Tx, both errata will never happen with a 100% of confidence. Just be aware of the self-received CAN message.
btw, the use of a single RX MB is an additional workaround for both erratas. Need to update errata manual soon with this information.
Errata details concerning to shadow MB and internal connections are not necessary to be stated, since there is no workaround at that level.
Hope this closes the issue
Regards
Hello Paolo:
Last week or so i was observing a case where the message was getting through a mailbox thats its not registered to. However when it does this, it doesnt reprogram the mailbox. Is this case possible?
Pseudo code:
Mailbox 1 configured to receive MSG 1
Mailbox 2 configured to receive MSG2
mailbox 3 configured to receive MSG3.
Earlier when MSG1 , MSG2, MSG3 had matching MSG_ID high, then MSG3 got through mailbox 1 and because of this, Mailbox for reprogrammed to receive MSG 3, and hence MSG1's failed to be received.
Now I made sure that MSG_ID high were unique in all three messages. In this case, i sometimes find MSG3 getting through Mailbox 1 but IT DOESNT reprogram Mailbox 1 . This way, MSG3 found an alternate path though Mailbox 1 withought corrupting mailbox 1. Thus MSG1's are also received.
Inside my ISR, everytime I receive a CAN message, I copy it into local memory. However instead of copying all the data bytes as received in the CAN message, I re-write CAn byte 0 with Mailbox number. This way, when the application gets the message, it know which mailbox it came from.
Thanks in advance.
sandeep
Hi Sandeep
THis part of the message seems unclear to me:
Inside my ISR, everytime I receive a CAN message, I copy it into local memory. However instead of copying all the data bytes as received in the CAN message, I re-write CAn byte 0 with Mailbox number. This way, when the application gets the message, it know which mailbox it came from.
Some questions:
1. Can you explain more if you are writing to MB directly? Are you unlocking/locking MB during this operation? More details about the quote.
2. Is there a Tx MB?
Hello Paolo:
thanks for your response.I can explain this in another way:
1.I have three mailboxes condifured to receive MSG1, MSG2 and MSG3 respectively.
2. The bus is heavily loaded with MSG1, MSG2 MSG3 sent back to back at about 2ms.
3. There is NO match in MSG ID high.
4. Upon reception of a CAN message, CAN ISR gets called.
5. I loop through the Mailboxes and see which mailbox had an RX message.
6. When a mailbox is found to have a message, i read the contents of the mailbox and copy it into a local memory Structure ( CAN structure)
7. At this time, I tag in the mailbox number in the CAN message structure. (The first data byte in the local CAN message structure is the message buffer # ).
8. The application, then gets this CAN message structure and looks at which mailbox the message actually came from. Ex: For MSG1 ,intended to come from Mailbox 7, an error could be the application receiving MSG 1 from Mailbox 8 and not mailbox 7. MSG2 is intended to come from Mailbox 8 and not MSG1.
9. I see some errors, but what surprises me is that although MSG 1 comes from Mailbox 8, it doesnt corrupt mailbox 8. Messages (MSG2) initially intended to come via mailbox 8 still make it through mailbox 8.
10 . There is a Tx mailbox but I am not transmitting anything. I am just receiving. Thus I am NOT writing anything to the mailbox. i am just reading Mailboxes.
So i wasnt sure if there could be a case where messages could come through different mailboxes, without corrupting them? If I can recollect, earlier errata showed that when a message comes from a 'wrong' mailbox, it corrupts that mailbox.
Hope this helps.
Here is a new (2/2009) erratum for certain CF processors (at least the 5216 and 5282):
Description:
Access to any field of a FlexCAN Message Buffer (MB) during reception or transmission of an extended ID frame's CRC and EOF may cause unwanted message reception.
Impact:
With extended ID frames, if the ID_HIGH received matches the ID_HIGH configured in a receive MB, the frame will be received to this MB irrespective of the ID_LOW and the mask. So unwanted messages which should be filtered by the hardware mask register may be received.
This issue only happens to the messages with the extended ID when ID_HIGH of the receive MB is equal to that of the current receiving frame.
Messages with standard ID have no such issue.
Workaround:
Perform one of these actions, either a or b:
a. Use only the Standard ID format for all messages, not the extended format.
b. In case extended IDs are used, make sure that only ID bits 28 to 15 are used as the filter criteria, so that other ID bits (ID bits 14 to 0) are not used to filter messages. ID bits 14 to 0 may contain information not used for message filtering purposes.