CAN RX FIFO overflow handling in STM32F4 FW package V1.16.0

[Blacbird]

Posted on July 27, 2017 at 20:20

Hiho,

we recently updated one of our projects to the newest Firmware package and had to realize that receiving CAN Messages per Interrupt did not work reliably anymore. We were able to track the problem down to the fact that multiple STM32F4 controllers were communicating over the same bus, and when switching on the power supply some RX FIFOs registered an overflow before the messages could be handled.

So far we did not find a way to get rid of this problem without modifying the drivers (which would be annoying without end with cubeMX) and reverted to V1.15.0. Does anyone know a nice way to cope with the swich-on overflow while using the HAL_CAN_Receive_IT functions? As they enable the FOV interrupts whenever they are called and the HAL_CAN_IRQHandler automatically disables the interface when a FOV flag is set, we have no clue so far.

Cheers,

Tobias Schwering

Blacbird Technologies UG

[Amel NASRI]

Posted on July 31, 2017 at 18:14

Hi

Bodensteiner.Fabian

‌,

I don't see where exactly is the CAN instance disabled in case FIFOx Overrun error.

When checking theHAL_CAN_IRQHandler, all the errors are managed inHAL_CAN_ErrorCallback which should be implemented in your application.

Could you please more details on this regard?

-Amel

[valentin]

Posted on July 31, 2017 at 22:51

You could check in your ISR if the FIFO is nearing completely full (e.g. 2/3 slots used?).

And then just transmit a extid 0x0 message with DLC=8 and all data bytes = 0x0. make sure to ignore that message on all participating nodes. Then the only effect of doing that is that it gives every node on the bus time to process their fifo queues - as the bus is held in a busy state, ergo no new transmissions coming from anywhere.

I think it should even free up the processor of the transmitting node if you use CAN_Transmit_IT as the bxCAN hardware handles the transmitting and while transmitting, the ISR can continue processing.

That technique works pretty well for me.

[Blacbird]

Posted on August 07, 2017 at 09:21

Hi Amel,

the HAL_CAN_IRQHandler sets the state of the can bus to ready and disables all interrupts before entering the HAL_CAN_ErrorCallback, thus ending the reception of further messages by interrupt when the user does not actively restart the reception in the callback. We figured out this possibility in the meantime, but think that this increases the entry threshold for new users trying to use the can interface. So far this is the first time that we found an application where implementing the can error callback is necessary in 5 years using ST microcontrollers.

And sorry for the slightly embarrassing forum name, this seams to be quite an old profile of the company .

Cheers,

Tobias Schwering

Blacbird Technologies UG

[Blacbird · Accepted solution]

Posted on August 07, 2017 at 09:28

After the controllers are fully booted we do not encounter any problems with full FIFOs as all messages are processed in time. We only have problems when starting up, so your strategy of keeping the CAN busy does not really work there. As we only transmit cyclic messages, it is also no problem to discard some messages in case they cannot be processed in time, so we prefer this approach to blocking actively blocking the arrival of new messages.