Overflow flag in STM32L4xx

[dirkmb]

CanOpenSTM32/CANopenNode_STM32/CO_driver_STM32.c

Line 407 in c7fb1de

// I didn't find overflow error register in STM32, if you find it please let me know

I found this comment. The STM32L4xxb and STM32F4xx sets the FOVR flag in the CAN_RFxR Register when an overrun occurs. I think overrun in STM language is the same as overflow in CanOpen language. This flag exists for each receive fifo.

STM Reference manual manual says:

Overrun
Once the FIFO is in pending_3 state (i.e. the three mailboxes are full) the next valid
message reception will lead to an overrun and a message will be lost. The hardware
signals the overrun condition by setting the FOVR bit in the CAN_RFR register.

Not sure if the flag also exists when using the FDCAN driver.

[MaJerle]

Buffer overflow in canopen is not the same as can overflow on a hardqare level.

[dirkmb]

Two questions:

1. what does an overflow in canopen mean?
2. if canopen not interrested in the information when messages have been lost on the bus?

[MaJerle]

1. If it is at the specific buffer level, then it means that CPU didn't process CANopen stack fast enough. Problem if that this overflow is specific to CANopen ID (SDO, PDO, NMT, ...) while buffer overflow at HW level can only tell that there was data misread, and not which buffer is problematic.
2. I cannot answer this.

[HamedJafarzadeh]

2. if canopen not interrested in the information when messages have been lost on the bus?

It actually does care. Look here : https://github.com/CANopenNode/CANopenNode/blob/8c7d852902b2d307e8b91a43332c14e366641e00/301/CO_Emergency.c#L580

I will mark this as enhancement to consider for next release.

[Nadreoh]

I found an issue that looks related to this ticket.
In the latest version(b084ab2) of CO_driver_STM32.c, a hardware Tx overflow flag is set (line 344: CO_CAN_ERRTX_OVERFLOW), but it is never reset in the code.
This flag triggers a safety mechanism and switches to pre-operational mode. But the code remains stuck in this pre-operational mode, because this flag is never reset (I do activate the MACRO to allow the code to automatically jump back to operational mode).

Here's my use case where I detected this problem: I have a single ST device connected to my laptop via a CANbox (PCAN-USB). For some reason, I disconnect my CANbox. The device is left alone on the bus and can no longer communicate. The Tx overflow flag is raised.

I'll try to figure out how to reset this flag "correctly" and let you know if I succeed.