I have a CAN-FD bus with multiple nodes communicating with a master node. One of the nodes has a faulty oscillator connected to the CAN-FD controller. The oscillator drifts from the designed 40Mhz output to approximately 44Mhz on random power cycles. When this happens, the node starts up with an incorrect baudrate. When this node transmits a message, it naturally doesn't receive an acknowledgement and tries to retransmit the message. After certain number of retries the node goes into Error Passive state and still keeps flooding the CAN-FD bus with retry attempts to transmit the message. I observed the node stays in the Error Passive state while flooding the CAN-FD bus but never goes BUS OFF. Is this behavior normal according to the CAN standard or the node needs to go into BUS OFF state and the failure to do so is something to do with the driver for the CAN controller?

Are you certain it isn't going into BUS OFF?  Have you set breakpoints to know this?  Since BUS OFF is not a permanent state it is possible that the node is repeating its errant behaviour once the condition for the termination of BUS OFF has occurred.  The facile response here is 'fix your hardware', but your case is an interesting one - how does one recover from an faulty clock reference?  One suggestion is to implement a transmit abort within the error handler of the CAN driver.  I haven't met a CAN peripheral yet that doesn't have this feature.  It may not save the node from failure but it will reduce bus pollution.

My experience with high level CAN drivers is that they are often weak wrt error handling.  CAN generally 'just works'.  If a transmission fails consistently it can mean that the node is talking to no one (no ACK is an error - a CAN bus must have more than one participant).  It can also mean that the other end of the bus is not able to wakeup from a sleep condition (some transceivers provide a CAN Rx wakeup interrupt to the attached micro - you might need to abort and retry to allow for startup latencies).  Your case is not normal since the clock is messed up and the peripheral might not be able to properly detect an ACK or error frame.  Read the peripheral documentation and understand how error registers work.  Don't ignore the error interrupt if your hardware has one.

Use of an LED to blink out error codes could be helpful if there isn't an alternate communication channel or error logging.

-rob

Hi, 

this has nothing to do with the driver. I have tested several CANs and with a baud rate mismatch or no CAN bus connection, the node at most reached a passive error and never BUS OFF. I could get a BUS OFF error by shorting the H and L lines. But even if the NODE goes BUS OFF, there is no guarantee that it will stop flooding the bus. It depends on the automatic recovery settings.