CAN error counters and interrupts

0
votes

I'm using the bxCAN peripheral of an STMF3 uC in an environment where

1.) it is essential that the node is detached from the network once the REC/TEC has reached the warning level (waiting for the bus-off condition is not an option)

2.) the baud rate of the host network is unknown

3.) the connection might be sporadic as the node is connected by the user

Due to 1.) the STM32 HAL CAN driver is used in IT mode and whenever the called with the EWG flag set, the error callback shuts down the transceiver and deinitializes the bxCAN. In case the REC is over the limit, it is easily recovered by configuring the bxCAN in silent mode, assuming there is traffic on the CAN. However, if the TEC is over the limit, the bxCAN won't be able to transmit an other frame as the error interrupt will be instantly triggered once enabled -> there we are in a deadlock.

I tried decrementing the TEC by transmitting frames in silent loopback mode but successful transmissions do not affect the TEC in this mode it seems.

I suppose the question is not specific to this peripheral but valid for other CAN implementations.

Any suggestions are welcome.

1
embeddedmicrocontrollerstm32can-busisr
If TEC is over the limit, you'd be in bus off and it would be recovered by seeing enough good receive traffic, not by transmitting. It sounds like the uniqueness of your problem may come from kind of trying to simulate bus off and recovery from a lower threshold. Can you do a hardware reset of the entire CAN block in the MCU? – Chris Stratton
Exactly so @ChrisStratton. Unfortunately the CAN peripheral in use has a safety feature so that requesting a master reset does not affect the error counters. I do understand what I'm trying to achieve is not exactly standard behavior, but it is essential that my node fails silently and other nodes are not informed. – gyorig
It sounds like the only unusual part of your problem is not wanting to wait for the hard error limit and bus off, to do what is otherwise a usual recovery flow. Can you at the lower threshold go into loopback or silent mode, somehow quickly cause enough errors to drive it into bus off, and then follow the normal recovery process? – Chris Stratton
But taking a step back, how do you think any of this is going to help? What does dropping off the network and recovering quickly do to help anyone else? Why not just back off in your activity a bit if you think congestion is at fault, or shut down permanently if you think you're broken, and otherwise let the normal healing mechanisms work? – Chris Stratton
try configuring listen only mode/ limp home mode and then change the mode does it affect the counter? – Sivaramakrishna Shriraam

1 Answers

1
votes

I have implemented a work-around that seems to work fine, with the following requirements:

1.) whenever the CAN error ISR is triggered, it disconnects the node from the bus (the transceiver is powered off)

2.) not all interrupt sources are enabled, only the ones that are of higher severity than the last error state (e.g. in PASSIVE state the WARNING and PASSIVE interrupts are disabled and the BUSOFF interrupt is enabled)

3.) the last error state and thus the interrupt sources are updated whenever a.) an error ISR is triggered or b.) polling the CAN peripheral with a high frequency shows change in the error state

4.) whenever attempting a connection to the bus the REC must heal in listen-only mode first. For this, traffic is required on the bus.

With these requirements implemented the node is able to fail silently but recover to normal operation.