FlexCAN stuck in interrupt loop

[christianmächle]

Hi,

There is a bug in the FlexCAN module of SDK 1.8.7 where the controller gets stuck in an interrupt loop.

This issue often occurs when using the RX FIFO but can also occur when using message boxes.

Explanation:

Under certain circumstances the FLEXCAN_IRQHandler can reset the status of a message box to FLEXCAN_MB_IDLE without resetting the IFLAG of the message box.

In this case, when the FLEXCAN_IRQHandler exists, the CAN interrupt is immediately called again (since the IFLAG of the message box is still active) and executes the FLEXCAN_IRQHandler again.

The FLEXCAN_IRQHandler realizes that the IFLAG of the message box is set, but since the status of this message box was already reset to FLEXCAN_MB_IDLE, the FLEXCAN_IRQHandler does not service the message box and exits without resetting the IFLAG. In that case the CAN interrupt is called again and so on.

The controller is then stuck in an interrupt loop.

Solution:

This failure can be avoided by adding

else
{
 FLEXCAN_ClearMsgBuffIntStatusFlag(base, mb_idx);
}‍‍‍‍‍‍‍‍‍‍‍‍

after line 1196 of flexcan_driver.c#

[islam1]

Hello All,

we upgraded to SDK 4.0.0 and the issue is not occurring anymore (Release note also states that this release fixes that issue ).. so we consider this closed 

Thanks all for your help!

[khaipham]

Hi,

I got the same issue in the SDK 3.0.2. The root cause of this issue is the IMASK1 flag of a mailbox is set while its state is IDLE. This results in an unexpected interrupt occurring.

Pre-condition:

• Using at least two mailboxes for transmitting or receiving, it is not necessary to enable Rx FIFO.
• Make a high bus traffic environment.

Explanation:

The function FLEXCAN_SetMsgBuffIntCmd is used to set or clear the IMASK flag of a specific mailbox ID. The following code in this function shall cause the problem.

...

if (enable)
{
(base->IMASK1) = ((base ->IMASK1) | (temp));
}
else
{
(base->IMASK1) = ((base->IMASK1) & ~(temp));
}

...

This "(base-> IMASK1) = ((base -> IMASK1) | (temp))" expression is not an atomic block. So that, a FlexCAN interrupt will probably interrupt this expression. In this case, the other mailbox IMASK flags that were cleared by the ISR are now re-set.

Resolution:

Add the expression into an atomic block.

DISABLE_INTERRUPTS();
(base->IMASK1) = ((base ->IMASK1) | (temp));
ENABLE_INTERRUPTS();

Hope this helps.

[raresvasile]

Hi,

There were some updates made in the FLEXCAN IRQ handler which should fix this issue.

But can you provide more details for the "certain circumstances"? We need to make sure that the scenario which you describes is covered by our updates.

Thank you,

Rares

[christianmächle]

Hi,

Unfortunately we did not investigate the root cause of the error further.

For our application we are using the ISELED driver together with the FlexCAN driver. The goal is to send about 50 CAN messages back to back to the microcontroller every 30ms. We noticed that if we sat up the FlexCAN driver as RX FIFO and do not clear the RX FIFO fast enough during that burst of CAN messages, that the driver would be stuck in that loop.

We could also halt the controller in debug mode while sending that burst of messages and after we let the application run again, the controller would be stuck in this loop.

I hope this helps you.

[islam1]

Hello raresvasile,

I have the same issue , i am using SDK v3.00 , was this issue fixed in later versions?

Thanks

Regards

[christianmächle]

Hi,

we updated to SDK 3.0.2 with ISELED driver 4.0.0 and so far had no further problems with the FlexCAN driver itself. That being said, when we want to read data from the ISELEDs, sometimes the ISELED driver will override part of RAM, which for us coincidentally holds the runtime data of the FlexCAN driver (time stamps, flexcan driver states). When this happens, the FlexCAN driver often gets stuck in an interrupt loop again. I created another thread for this issue (S32K ISELED buffer override ). So there still there seems to be some cross over effects using the ISELED driver and FlexCAN driver, at least for us.