CODEWITHSUNDEEP
embeddedcan-bus
Steve
Steve

Reputation: 859

communication lost detection CAN

I have been implementing motor control software. This control software runs in one microcontroller which communicates with different microcontroller over CAN bus. I need information about CAN "failure" (communication lost) in the control software. I am not sure what could be the appropriate symptom of the CAN "failure". I have an idea that I would check whether the CAN periphery is in the Bus off state. If so, I would trigger some timer and after expiration of for example 1 s I would take the communication for lost. As soon as the CAN periphery transits into the Error active state I would take the communication for secure again. Is it possible or anybody solve this in different manner? Thanks for any ideas.

Upvotes: 1

Views: 1200

Answers (1)

Lundin
Lundin

Reputation: 213892

There are two completely different things to consider:

  1. On the application level, does whoever you are communicating with respond in time and do they send valid data?
  2. Are there hardware errors on the CAN bus?

Regarding 2), bus-off and CAN error frames are hardware errors, usually caused by rather severe things such as incorrect installation, short between CAN high/low, bad wires/connectors, EMI noise, bad/no termination, crappy signal ground and/or shield etc. These are mostly non-recoverable errors that the software can't do much about. The only thing you can do is to display some diagnostics.

Rather than messing around and examining various CAN bus errors, this kind of rugged firmware (assuming industry/automotive) should be designed so that it just checks if you have received correct data in time, as required by 1). Because that's the only thing that is relevant to you. If the bus is feeling ill, if there are error frames, but you are still receiving data - fine, just keep running for as long as you are able.

So the only thing of interest is to use a timer with a sensible timeout - depending on how fast the controlled machine is moving (500ms is a general industry standard, though faster machines might need a shorter timeout). Each time you receive a valid (series of) CAN package(s) you refresh this timer. When the timer elapses, revert to a safe state.

When/how to recover from the safe state is highly application-specific. Many safety-critical applications forbid a recovery from a critical error without an explicit command from an operator.

Upvotes: 3

Related Questions