CANopenNode / CanOpenSTM32

CANopenNode on STM32 microcontrollers.
Other
275 stars 110 forks source link

Overflow flag in STM32L4xx #43

Open dirkmb opened 11 months ago

dirkmb commented 11 months ago

https://github.com/CANopenNode/CanOpenSTM32/blob/c7fb1def182dfee394f396739e5cc45b11f744cc/CANopenNode_STM32/CO_driver_STM32.c#L407

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 commented 11 months ago

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

dirkmb commented 11 months ago

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 commented 11 months ago
  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 commented 7 months ago

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 commented 3 months ago

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.