What Is a CAN Error Frame?
CAN was designed for hostile environments, and its error handling is what lets one bus keep running when a node or a wire starts misbehaving. Central to that is the error frame and the counters behind it, which quietly promote a troubled node through progressively more cautious states and, if it keeps failing, take it off the bus entirely so it stops disrupting everyone else. This page explains what an error frame is, how the error counters drive the error-active, error-passive, and bus-off states, and what going bus-off actually means in the field.
CAN Error Frame in one line: A CAN error frame is a special message a node transmits the instant it detects a corrupted frame, which forces every node to discard that message and the transmitter to retry. CAN keeps transmit and receive error counters, and as a node's errors accumulate it moves from error-active to error-passive and finally to bus-off, where it stops transmitting to protect the rest of the bus. This is called fault confinement.
How an Error Frame Works
When any node detects a violation, such as a bit it did not expect, a stuff-rule breach, a bad CRC, a framing error, or a missing acknowledgment, it immediately transmits an error frame. The error frame is deliberately a run of dominant bits that deliberately violates the normal framing rules, which forces every other node to also see an error and discard the message in progress. This global signaling means that when one node spots corruption, the whole bus agrees to throw that frame away, and the original transmitter retransmits it.
This is what makes CAN robust rather than merely detecting errors: a corrupted frame is not just flagged, it is actively destroyed on the wire and retried, so consumers never act on bad data. The cost is bus time, and a node that keeps generating errors keeps consuming that time, which is exactly why CAN needs a mechanism to identify and isolate a persistently faulty node before it starves the bus of capacity.
Error Counters and the Three States
Every CAN controller maintains a transmit error counter and a receive error counter. Detecting an error increases the relevant counter by a defined step; successfully sending or receiving a frame decreases it. This weighting is intentional: a node that is itself the source of trouble accumulates transmit errors faster than a healthy node merely witnessing them, so the counters tend to point at the actual culprit rather than at an innocent bystander.
The counters drive three states. A node starts error-active, meaning it participates fully and signals errors with dominant error frames that the whole bus hears. When its error count crosses a threshold it becomes error-passive: it still communicates but signals errors more quietly, so a struggling node cannot dominate the bus with error frames. If the transmit error counter climbs past the bus-off threshold, the node goes bus-off, disconnects itself from the bus, and stops transmitting entirely. Most controllers also raise an error-warning flag before the passive threshold, giving software early notice that a node is in trouble.
This staged demotion is called fault confinement, and it is the reason a single bad node does not permanently take down a CAN network. A device with a marginal transceiver or a wiring fault will accumulate errors, drop to error-passive, and if it keeps failing go bus-off, at which point the rest of the bus recovers and continues without it. Recovery from bus-off typically requires the controller to be reset or to observe a defined idle period, which is a software decision, not automatic in every implementation.
What Bus-Off Means in the Field
When a node goes bus-off, its data simply stops appearing, while the rest of the bus keeps running. That asymmetry is a useful diagnostic clue: if one device's tags freeze or disappear while every other node on the same bus updates normally, the failed node has very likely gone bus-off, and the fault is local to that node's transceiver, wiring, or connector rather than a bus-wide problem. A bus-wide fault, by contrast, takes many nodes down together.
Because bus-off is triggered by accumulated transmit errors, its usual root causes are physical: a specific node's damaged transceiver, a loose or corroded connector on that drop, a wiring error on that stub, or a baud-rate mismatch that makes that one node see errors constantly. Chasing it means going to the offending node's physical layer, not rewriting message logic, which is the same approach as any CAN bus troubleshooting workflow.
Through a monitoring gateway, none of the error-counter machinery is visible directly, but its result is unmistakable: one node's data stalls or goes stale while its neighbors keep reporting. A time-series record that shows a single device dropping out repeatedly, each time recovering after a reset interval, is the signature of a node cycling into bus-off, and it tells you exactly which drop to inspect at the wire.
Frequently Asked Questions
What causes a CAN node to go bus-off?
A node goes bus-off when its transmit error counter climbs past the bus-off threshold, which happens when it repeatedly detects transmission errors. The usual root causes are physical and local to that node: a failing transceiver, a loose or corroded connector, a wiring fault on its stub, or a baud-rate mismatch that makes it see constant errors. In bus-off the node disconnects and stops transmitting so the rest of the bus keeps running.
What is the difference between error-active and error-passive on CAN?
Error-active is the normal state, where a node participates fully and signals detected errors with dominant error frames that the whole bus hears. When its error counters cross a threshold it becomes error-passive: it still communicates but signals errors more quietly, so a struggling node cannot flood the bus with error frames. Error-passive is a warning stage on the path toward bus-off if the errors continue.
Does one bad CAN node take down the whole bus?
Usually not, thanks to fault confinement. A persistently faulty node accumulates errors faster than healthy nodes, drops to error-passive, and if it keeps failing goes bus-off and disconnects itself, after which the remaining nodes recover and continue. If instead every node fails together, the fault is bus-wide, such as missing termination or a shorted pair, rather than a single bad device.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.