SAMC21 CAN errata "Message transmitted with wrong arbitration and control fields

[Tingy]

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.pdf
lists 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.

[ataradov]

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.

[Tingy]

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.

[Tingy]

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 second
and third bit of intermission, the application software can
evaluate 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 interval
has passed or when the CAN is safely idle. The danger interval is identified by using the CAN receive interrupt handler
coupled 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_RF0NE
is 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 end
of 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 equivalent
to at least CAN-bus 3-bit periods and at the end of this interval, TC0 overflow interrupt is triggered, and
if 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 the
   end 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 but
   must be received in order to trigger interrupts at the end of every message. Although, this is not essential
   if transmitted messages are scheduled at the same rate as received messages that are processed, in which case
   interrupts 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 critical
   danger time between messages.

The full source code for this workaround example is attached in a zip, hope this helps anyone else who needs
to create a workaround.