Blog
CAN Bus Error Handling: How Error Detection, Confinement, and Bus-Off Recovery Work
July 16, 2026
CAN bus was designed for environments where noise, wiring faults, and marginal signal integrity are the norm, not the exception — engine bays, industrial floors, vehicle chassis. What makes it genuinely reliable in those conditions isn't the absence of errors; it's that error detection and fault confinement are built into the protocol itself, not bolted on as an afterthought. Every CAN controller on the bus is constantly counting errors and deciding, frame by frame, whether it's still healthy enough to participate.
This article breaks down exactly how that mechanism works: the error types CAN detects, how error counters and error states function, and what actually happens when a node goes bus-off.
CAN bus is a multi-master, broadcast network where every node can transmit and every node is expected to catch corrupted messages before they cause downstream problems — there's no central arbiter checking data integrity. If error detection were left to the application layer, a single noisy sensor or a wiring fault could silently corrupt data across an entire vehicle or machine network without anyone noticing until a system misbehaved.
CAN solves this by making error detection a hardware-level responsibility of every controller on the bus, checked on every single frame, with a shared mechanism for signaling problems and a self-regulating system for isolating misbehaving nodes.
Every CAN controller checks each frame against five categories of error:
| Error Type | What It Detects |
|---|---|
| Bit Error | A node transmits a bit and, monitoring the bus while sending, reads back a different value than what it sent (outside of expected arbitration/ACK behavior) |
| Stuff Error | A violation of the bit-stuffing rule — CAN inserts an opposite-polarity bit after five consecutive identical bits, and a receiver checks that this pattern is respected |
| CRC Error | The 15-bit CRC calculated by the receiver doesn't match the CRC field transmitted in the frame, meaning the payload was corrupted in transit |
| Form Error | A fixed-format field in the frame (like the CRC delimiter, ACK delimiter, or end-of-frame sequence) doesn't contain the expected fixed bit pattern |
| Acknowledgment (ACK) Error | The transmitter doesn't see a dominant bit in the ACK slot, meaning no receiving node acknowledged successful receipt of the frame |
When any node detects one of these errors, it doesn't just silently drop the frame — it actively signals the problem to the entire bus.
The moment a node detects an error, it immediately transmits an error frame — a sequence of six consecutive dominant bits (violating the bit-stuffing rule on purpose) called the Error Flag, followed by an Error Delimiter of recessive bits. Because this deliberately breaks the stuffing rule, every other node on the bus also detects a stuffing violation and joins in signaling the error, which is why a single detected error causes the entire current frame to be aborted and retransmitted by the original transmitter — not silently ignored.
This is a deliberate design choice: rather than one node quietly rejecting a bad frame, CAN makes error detection a bus-wide, immediate event, so corrupted data never gets accepted by only some nodes while others act on it.
Every CAN controller maintains two internal counters defined by the CAN specification:
These counters increase when a node detects errors (or when its own transmissions are rejected by others) and decrease gradually during successful, error-free communication. The exact increment/decrement rules differ depending on the role (transmitter vs. receiver) and error type, but the general behavior is:
This asymmetric increment/decrement design means a node that's occasionally seeing errors in an otherwise healthy bus recovers its counter over time, while a node that's persistently causing or seeing errors escalates toward a fault state — the counters function as a rolling health score, not a simple pass/fail flag.
Based on the values of TEC and REC, every node sits in one of three fault confinement states:
| State | Condition | Behavior |
|---|---|---|
| Error Active | TEC < 128 and REC < 128 | Normal operation. Node participates fully and transmits active error flags (dominant bits) when it detects a problem |
| Error Passive | TEC ≥ 128 or REC ≥ 128 (but TEC ≤ 255) | Node still participates in the bus, but transmits passive error flags (recessive bits, which don't force other nodes off the bus) and must wait an extra delay before transmitting |
| Bus-Off | TEC > 255 | Node disconnects itself from the bus entirely and stops transmitting until a defined recovery sequence completes |
This three-tier escalation is the core of CAN's fault confinement strategy, often summarized as: a node that's causing problems for the bus should progressively lose its ability to disrupt the bus further, rather than continuing to broadcast error signals that degrade communication for every other node.
An error-active node signals errors with dominant bits, which — because dominant beats recessive in CAN's bus arbitration logic — can actively disrupt ongoing bus traffic. An error-passive node is intentionally downgraded to signaling errors with recessive bits precisely so that a node with a demonstrated fault history can no longer forcibly interrupt other nodes' communication, even while it's still allowed to participate normally otherwise.
When a node's Transmit Error Counter exceeds 255, it enters Bus-Off state — it electrically stops driving the bus and can no longer transmit or receive (aside from monitoring for the recovery condition). This is CAN's most severe fault confinement mechanism: rather than letting a badly malfunctioning node keep disrupting the network indefinitely, the protocol forces it to remove itself entirely.
Recovery from bus-off isn't automatic in the sense of "just start transmitting again" — the CAN specification defines a specific recovery sequence:
This design ensures a recovering node only rejoins the bus once there's actual evidence the bus is quiet and healthy again — not just after an arbitrary timeout.
Monitor error counters proactively, not just bus-off events. A node sitting in Error Passive state for extended periods is a strong early warning sign of a wiring fault, termination problem, or noisy transceiver — waiting until bus-off actually happens means you've already lost that node's communication.
Differentiate systemic vs. transient errors in logging. A handful of CRC errors during a known noisy event (engine crank, relay switching) is expected bus behavior. A steadily climbing TEC/REC trend across many drive cycles usually points to a hardware-level problem — connector corrosion, a marginal termination resistor, a failing transceiver — that error counters alone won't diagnose without correlation over time.
Design bus-off recovery deliberately, don't just auto-retry blindly. Immediately and repeatedly attempting to reinitialize a bus-off node without back-off logic can itself contribute to bus instability if the underlying fault (a short circuit, a stuck-dominant node) hasn't cleared. Many production systems implement a bus-off recovery strategy with escalating delay and a fault-logging threshold before giving up and reporting a hard fault to a higher-level diagnostic system.
Watch for "babbling idiot" nodes. A node stuck transmitting continuously (due to a software bug or hardware fault) can dominate bus arbitration and starve other nodes even without technically causing classic bit/CRC errors. Some CAN controllers and transceivers include additional protection (like a hardware bus guardian or software-enforced transmission rate limits) specifically to catch this failure mode, since standard error counting alone doesn't always catch it quickly.
Use CAN error frames in diagnostics tooling. Analyzer tools (Vector CANoe, PCAN-View, Kvaser tools) can log and display raw error frames and per-node error counter trends, which is often the fastest way to localize an intermittent physical-layer fault during bring-up or field debugging, rather than relying solely on application-layer symptoms.
What causes a CAN node to go bus-off?
A node's Transmit Error Counter exceeding 255, which happens after repeated transmission errors — commonly caused by wiring faults, missing or incorrect bus termination, a failing transceiver, ground offset issues, or a node with a mismatched bit-timing configuration relative to the rest of the bus.
Can a bus-off node recover automatically?
Per the CAN specification, yes — after observing 128 occurrences of 11 consecutive recessive bits on the bus, the controller can reset its error counters and return to Error Active. Many microcontroller CAN peripherals handle the counting and reset in hardware, though the surrounding driver/application code often needs to explicitly restart the peripheral depending on the implementation.
What's the difference between error active and error passive states?
Error active nodes signal detected errors using dominant bits, which can actively interrupt other nodes' transmissions. Error passive nodes (triggered once TEC or REC reaches 128) signal errors using recessive bits instead, which don't interrupt ongoing traffic — a deliberate downgrade so a node with a poor error history can't keep disrupting the bus for everyone else.
Do all five CAN error types cause the same increase in error counters?
No — the CAN specification's counter increment rules vary depending on whether the node is a transmitter or receiver and the specific error type detected, with transmission-side errors generally penalized more heavily than reception-side errors, reflecting that a misbehaving transmitter poses more risk to overall bus health.
Is a rising error counter always a hardware problem?
Not necessarily on its own — transient error counter increases can happen during expected electrically noisy events. But a persistent upward trend across many operating cycles, rather than isolated spikes tied to known noise events, is a strong signal of an underlying physical-layer issue worth investigating.