SAMC21 CAN errata "Message transmitted with wrong arbitration and control fields - Page 1
Forum section: electronics / general

author: Tingy
author_rank: Newbie
timestamp: November 25, 2022, 05:29:40 pm
content: Hi,The "SAM C20/C21 Family Silicon Errata and Data Sheet Clarification" which is available here :https://ww1.microchip.com/downloads/aemDocuments/documents/MCU32/ProductDocuments/Errata/SAM-C20-C21-Family-Silicon-Errata-and-Data-Sheet-Clarification-DS80000740.pdflists an issue with the CAN peripheral under errata 1.6.18, stating :"Under the following conditions a message with wrong ID, format, and DLC is transmitted".An internet search reveals the SAMC21 isn't the only micro-controller family with this errata. Errata sheets for SAMA5D2, DRA78x, AWR1642, IWR1642 from TI, MPC5777C from NXP, all list the same issue and the commonality is "M_CAN".The M_CAN is a CAN IP module licensed from Bosch :www.bosch-semiconductors.com/ip-modules/can-ip-modules/m-can/We are creating embedded nodes that sit on 3rd party CAN bus and transmissions of the wrong ID are not acceptable as they might be incorrectly acted on.I would like to know if this affects the SAMC21 at any CAN bus speed, classic CAN, CAN_FD or both, and if the wrong ID is a fixed value or random.Sadly, the errata sheets do not go into that detail although the TI errata sheets implies the problem is applicable to CAN_FD.I have tried contacting both Microchip and Bosch for support but without success.If anyone is familiar with this problem and can offer any further information it would be very welcome.

author: ataradov
author_rank: Super Contributor
timestamp: November 25, 2022, 07:09:35 pm
content: This would apply to both CAN and CAN FD modes at any speed. No idea what values would be used instead of the requested ones. I think TI errata just mentions CAN FD as a generic name of the peripheral.There are a couple workarounds provided in the errata. Just implement one of them.

author: Tingy
author_rank: Newbie
timestamp: December 01, 2022, 03:29:21 pm
content: Hi Alex,Thank you for confirming. I am working on code for one of the workarounds and will post that, when it is ready, in case it is useful to others.

author: Tingy
author_rank: Newbie
timestamp: December 08, 2022, 10:40:09 am
content: The workaround I have tested is number 1 : Request a new transmission only when CAN is not in the Receiver state.To avoid activating the transmission request in the critical time window between the sample points of the secondand third bit of intermission, the application software canevaluate the Rx interrupt flags, such as IR.DRX, IR.RF0N, and IR.RF1N, which are set at the last bit of End-of-Frame (EoF).The last bit of EoF is followed by three bits of intermission, or Inter-Frame-Space (IFS).Therefore the critical time window has safely terminated three bit times after the Rx interrupt.The basis of the workaround I have constructed is to transmit messages immediately after the danger intervalhas passed or when the CAN is safely idle. The danger interval is identified by using the CAN receive interrupt handlercoupled with a time interval, generated using TC0, equivalent to at least 3 bit periods.Messages which the node needs to process might be received into FIFO-0, for example. The interrupt CAN_IE_RF0NEis enabled to detect the end of such messages.Messages which the node would normally ignore are dumped into FIFO-1 so as to generate interrupts at the endof each bus message. Interrupt CAN_IE_RF1NE is enabled to detect the end of such messages.Upon detecting either of the above interrupts, TC0 is started to generate a short time interval equivalentto at least CAN-bus 3-bit periods and at the end of this interval, TC0 overflow interrupt is triggered, andif the code has a transmission pending, the transmission request flag is set immediately.The undesirable aspects of this workaround are :1) The simplicity and elegance of setting TXBAR whenever a message transmission is needed is thrown out of the window.2) It is necessary to receive all CAN messages from the bus in order to trigger a CAN interrupt at theend of each message. There is some overhead associated with this.3) One of the FIFOs must be dedicated to receiving the messages that do not need to be processed butmust be received in order to trigger interrupts at the end of every message. Although, this is not essentialif transmitted messages are scheduled at the same rate as received messages that are processed, in which caseinterrupts triggered after each message to be processed may suffice .4) An additional timer may need to be configured/ operated to time the delay until after the criticaldanger time between messages.The full source code for this workaround example is attached in a zip, hope this helps anyone else who needsto create a workaround.