LAUNCHXL-F28379D: How to avoid race condition to CAN IFX register?

Some More details from customer on this topic:

Problem: Even though the CCP block uses its own unique CAN TX mailbox registers for transmit (mailboxes 1 & 2), there is a conflict with the other CAN TX mailboxes, likely thru access to the IFx registers that indirectly access the CAN message RAM.

I was initially having problems with CAN TX signals in my own CAN transmit messages (same issue with intermittent incorrect/erroneous values), however after placing these CAN TX blocks in a non-preemptable interrupt service routine, the signal data is no longer corrupted.
To test if the CAN TX blocks are interfering with the CCP TX messages, I removed all other CAN TX blocks and the CCP DAQ signals have no problem. NOTE:: I have no control over when the CCP block tries to access the IFx registers to set a CAN TX message and whether the task is pre-emptable, so it would seem these other CAN TX blocks have the ability to overwrite what the CCP block is trying to write to the CAN message RAM. The opposite was true before moving the other CAN TX blocks to their own non-preemptable interrupt service routine.

Venkatesh,

            In CAN, what is of concern is received message being “lost” i.e. an old received message being overwritten by a new message (in the same mailbox) before the application has had a chance to read the old message. This is because receive is asynchronous to the application code and could happen any time. 

For the transmit operation, the scenario you describe is possible. Regarding your observation “after placing these CAN TX blocks in a non-preemptable interrupt service routine, the signal data is no longer corrupted”, it is important to put things into perspective: Depending on the number of bits in a frame, it could take around 135 uS (MAX) to complete transmission , after a node wins bus arbitration. From a System clock perspective, this is a "very long" time, since it happens in the CAN bit-clock domain. However, transfer to/from IFx registers happen in the System clock domain, which should happen "very fast" , since we are now working in the realm of 5 ns cycle time. Now, you are talking about contention/corruption in the few cycles it takes for IFx transfer? 

There are two Interface Register sets, IF1 & IF2. Why not let CCP use IF1 set and the lower priority messages IF2? Is this doable?

Hi Hareesh,

Thank you so much for letting us know.

One thing I noticed is, from TI implementation of the CAN drivers we see the IF1 registers being used for the Tx of the message from CPU to message RAM while IF2 registers are being used for the Rx of the messages from message RAM to CPU. We implement our lower routines very much inline with TI. Having said that, all our CAN Tx blocks irrespective of if they are part of CCP block or are located in an ISR, would try to use the IF1 registers. At the same time all the CAN Rx blocks would use IF2 registers. Having said that, is it a good design case to use IF3 for Rx of message and make the IF1 and IF2 as configurable for CAN Tx? That is, a CAN Tx block can provide option for user to select between IF1 or IF2 register set for transferring data from CPU to message RAM? In that case, we can selectively make a set of CAN Tx block which execute from an interrupt context to use IF2 while the periodic blocks can use IF1 register. That way we can avoid the conflict. We can also extend this option for the CAN Rx blocks as well. But currently the TI implementation is hard coding CAN set and get interfaces to use the IF1 and IF2 register set. Please let me know if this doable and if this is good approach to take? Or are any other way of doing the same exist.

Hi Hareesh,

I see the CAN routines as shipped by TI are not re-entrant. Is there a scope for the same?
Or do we have version of them which we are not aware.