CAN Error Counters and the State Machine That Silences a Faulty Node

Every bus that several nodes share needs an answer to a specific question: what happens when one node’s transmitter degrades and starts corrupting traffic for everybody else? A protocol that only detects errors and requests retransmission will let a marginal node keep damaging the bus indefinitely, because each individual frame is rejected and retried and the retries are what fill the bus. CAN answers with an accounting scheme: each node keeps two error counters, and the counters decide whether the node is allowed to signal errors normally, whether it must be quiet, or whether it must disconnect itself.

Two counters with asymmetric penalties

A CAN controller maintains a transmit error counter and a receive error counter. Both are eight bits wide, both start at zero, and both are changed by fixed amounts when something goes wrong. The amounts differ depending on whether the node was transmitting or receiving at the time, and the asymmetry is the whole design.

A node that is transmitting and detects an error adds eight to its transmit counter. A node that is receiving and detects an error adds one to its receive counter. A successful transmission subtracts one from the transmit counter, and a successful reception subtracts one from the receive counter, though the decrement rules are conditioned on the counter’s current value so that a healthy node cannot drive its counter below zero.

The eight-to-one ratio encodes a judgement about blame. A transmitter that is sending corrupt data affects every receiver on the bus, and the corruption propagates: each receiver may report an error, and the transmitter is the common cause. A receiver that sees a corrupted frame has probably not caused it. Penalising transmitters eight times as fast means a genuinely faulty transmitter reaches a high count after a handful of bad frames, while a receiver that is merely unlucky in a noisy environment accumulates slowly.

There are refinements that matter in practice. A receiver that is the first to detect an error and raises the error flag increments by eight rather than one, because it takes responsibility for aborting the frame. The rules also cap how far a single increment can carry a counter, so a receiver near the error-passive threshold is not pushed past it in one step and no counter is allowed to wrap. And a successful reception decrements the counter only while it is above zero, so a healthy receiver does not accumulate credit against future errors.

The three states

The counter values partition the nodes into three states.

A node is error active while both counters are below 128. In this state it may transmit an active error flag, which is six consecutive dominant bits, and it may transmit normally.

A node is error passive when either counter reaches 128. Its ability to transmit is unchanged, but its ability to complain is not: it may only transmit a passive error flag, which is six consecutive recessive bits. On a bus where the dominant state is the asserted one, a passive error flag is invisible to other nodes, because any node driving dominant overrides it. An error passive node’s error is therefore not necessarily seen by the rest of the bus, and it cannot force the frame in progress to be aborted.

A node is bus off when its transmit counter exceeds 255. It is disconnected from the bus: it drives nothing, it receives nothing, and it does not acknowledge. Recovery requires the controller to observe a defined number of consecutive recessive bits — the specification’s figure is 128 occurrences of eleven recessive bits — after which the counters are cleared and the node returns as error active.

The transition into error passive also imposes a delay on transmission. A node that has just transmitted a frame while error passive must wait for eight additional bit times after the intermission before it may start another transmission. This is the suspend transmission rule, and its purpose is to give other nodes a chance to use the bus, so that a passive node with a flood of pending frames cannot monopolise it.

The reason for the extra eight bits is worth following. An error passive node cannot abort a frame with a dominant flag, so if it were allowed to retransmit immediately after a failed attempt it could enter a loop in which it transmits, an error occurs, the error is not globally detected, and it retransmits, consuming bus bandwidth without any frame ever completing. The suspend delay breaks the loop.

/* simplified counter update; the real rules have threshold exceptions */
enum can_state { ERROR_ACTIVE, ERROR_PASSIVE, BUS_OFF };

static enum can_state can_account(int *tec, int *rec, bool transmitting, bool success)
{
    if (success) {
        if (transmitting && *tec > 0)      (*tec)--;
        else if (!transmitting && *rec > 0) (*rec)--;
    } else if (transmitting) {
        *tec += 8;
    } else {
        *rec += 1;                          /* 8 if this node raised the flag first */
    }

    if (*tec > 255)             return BUS_OFF;
    if (*tec >= 128 || *rec >= 128) return ERROR_PASSIVE;
    return ERROR_ACTIVE;
}

The counters are visible to software on most controllers, and reading them is the cheapest diagnostic available. A node whose transmit counter climbs steadily while its receive counter stays near zero has a physical-layer problem on its own output. A node whose receive counter climbs while the transmit counter stays low is seeing errors caused by somebody else, which points at the wiring or at another node.

What each error type says about the cause

The controller classifies the error it detected, and the classification is the most useful thing it reports.

A bit error means the transmitter monitored the bus while sending and saw a different level than it drove. Either the bus is being overridden by another node — which should only happen during arbitration — or the physical layer is distorting the signal, or a transceiver is driving the wrong way. A bit error during arbitration is normal and does not increment any counter; it is the mechanism, not a fault. A bit error outside arbitration is a real fault.

A stuff error means six consecutive bits of the same polarity appeared where the stuffing rule forbids it. That is either a corrupted bit or a node that implemented stuffing incorrectly. The latter is a real and specific class of bug: a controller that stuffs a field the specification exempts will produce stuff errors on every receiver.

A form error means a fixed-format field had the wrong value: the CRC delimiter or the acknowledge delimiter was dominant where it must be recessive, or the end-of-frame sequence was broken. A form error almost always indicates corruption, because these fields are fixed constants that a correct transmitter cannot violate.

An acknowledge error means the transmitter completed a frame and saw no node drive the acknowledge slot dominant. On a bus with at least one other functioning node, this indicates that no receiver accepted the frame — the frame was corrupt, or the receivers were not there. On a bus with exactly one node, it indicates that there is nobody to acknowledge, which is the normal state of a single-node bus.

A CRC error means the check sequence did not match. It says the frame was corrupted but not where, and by itself it does not distinguish a bad transmitter from a noisy medium.

The acknowledge error deserves emphasis because it produces a well-known trap. A node connected to a bus with no other active nodes will transmit, receive no acknowledge, treat that as an error, increment its transmit counter by eight, and retransmit. With no backoff and no limit on retries other than the counter, the node climbs to bus-off after a few dozen attempts. A system that is brought up one node at a time, or whose other nodes are held in reset, therefore sees the first node go bus-off and stay there. Some controllers offer a listen-only or loopback mode that suppresses transmission and acknowledgement to make this testable, and some offer a configurable retry limit.

Fault confinement as a distributed decision

The scheme has no central arbiter. Each node decides about itself, using only its own observations, and the decision is enforced by the other nodes only indirectly: a bus-off node cannot participate because it does not drive the bus.

The property this produces is that a single faulty node degrades the bus rather than destroying it. A node with a stuck-dominant transmitter is the hard case, because a permanently dominant bus cannot carry any frame at all; the error counters of every other node climb as they fail to transmit or receive, and the whole bus converges toward bus-off. The counters do not fix a shorted line. They do fix a node whose transmitter is intermittently wrong, which is the far more common failure.

The counter values also give the system a usable early warning. A node in error passive state is still communicating but is one step from disconnection, and a diagnostic layer that polls the counters can see the trend before the node disappears. Most higher-layer CAN protocols define a way to report node state, and the counters are the natural input to it.

Recovery from bus-off is deliberately slow, because a node that has just been disconnected should not immediately return to a bus that it may have been disrupting. Implementations often expose a fast-recovery option that shortens the waiting period, and using it is a trade: faster return to service against a higher chance of a node oscillating between bus-off and active while the underlying fault persists. The default slow path is the safer one for a system that cannot be serviced in the field.

Where the accounting stops being enough

The counters are a link-layer mechanism and they see only what the link layer can see. They cannot distinguish a transceiver whose differential output has degraded from a cable with a missing terminator, because both produce the same bit and CRC errors at the same rate. They also cannot see a node that transmits frames with correct framing and wrong content: a sensor reporting a stale value, or a node with an incorrectly configured identifier, produces no errors at all.

Those cases need the layers above. The physical-layer causes are described in differential signalling and bus termination, the frame fields that the error types refer to are in CAN frame layout and bit stuffing, and the timing consequences of a node that keeps retrying are part of worst-case response time on a loaded bus.

The counters are nevertheless the part of CAN that most rewards understanding, because they are the only mechanism on the bus that acts on a fault without a host processor deciding to. A node that is damaging traffic takes itself off the bus, and it does so with a rule simple enough to verify.