STM32H753 FDCAN Bus Recovery

[CZuercher_Ilm]

Good Morning,

 

I'm struggling with FDCAN Bus Recovery.

The system we have to use consists of an STM32H753-based board and a 3rd party ECU, which is internally terminated via software. Our custom board is also terminated, resulting in the correct 60 Ohm between CAN Hi & CAN Lo.

In the event I add an additional termination resistor to the Bus, the power-up sequence doesn't matter, however the bus is the over-terminated, which is obviously not correct. I can, however, see the custom board initially blurting out a CAN frame as fast as it can before the other ECU has finished powering up, and then normal CAN comms is seen on PCAN (the PCAN has been configured to not send any Acks).

However, if I leave the bus as it is, it looks like the bus from the perspective of the custom board just turns off. I can see the 3rd party ECU splurging out one of its' messages as fast as it can, however our board should be seeing this message and transmitting Acks etc.

I have implemented the Bus-Off recovery specified in the documentation (waiting for the Bus-Off flag to be set in the PSR Register and then clearing the Init bit), but it seems not to work at all and the CAN Bus just remains in the Off State.

How should I rectify this issue without altering the power-up sequence of the ECU's?

[mƎALLEm]

Hello,

I invite you to review your Bus-off recovery implementation by reading this knowledge base article:

How to recover from Bus-Off state with FDCAN on STM32 MCUs

[Ozone]

> However, if I leave the bus as it is, it looks like the bus from the perspective of the custom board just turns off. I can see the 3rd party ECU splurging out one of its' messages as fast as it can, however our board should be seeing this message and transmitting Acks etc.

Having dealt with i similiar problem in another system, I had to disable (or not enable) CAN at initial hardware setup, clear all "flooded" CAN FIFOs (or other hardware receive buffers), and enable the CAN peripheral only when the application was ready for reception and processing.

In my case, I dealt with a CANopen ECU, which is supposed to initiate the CAN communication on the bus. However, this use case included a non-compliant device that didn't ever shut up, and was powered on before the ECU. Thus the problem had to be solved on the (CANopen) master node, the ECU.

For the bus-off, you would need to check the bus configuration, and physical signals.
If no other node exist on the bus (or is ready), transmitting node will quickly go into passive mode. This wasn't the case in my setup, with all sort of other nodes present (CANopen sensor devices) which would acknowledge messages.
A transmitting node should never go in bus-off state on a proper bus (unless the error-passive and bus-off error level are identical, which is not the default).