Open dirkmb opened 11 months ago
Buffer overflow in canopen is not the same as can overflow on a hardqare level.
Two questions:
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.
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.
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:
Not sure if the flag also exists when using the FDCAN driver.