What Causes a CAN Controller to Go Bus-Off, and How Do You Recover From It?

Detailed Explanation

CAN's fault confinement mechanism — covered at a high level in What Is CAN Bus? — is what makes the protocol tolerant of a genuinely broken node without taking the whole bus down. But that same mechanism means a node with a real problem doesn't just log an occasional error and carry on: past a defined threshold, it disconnects itself from the bus entirely, and depending on the peripheral, it may not come back without firmware doing something about it. This is one of the most common CAN field failures reported — a node worked fine on the bench, then silently stopped communicating after a noise event, a marginal connector, or a wiring change in the field.

The Transmit and Receive Error Counters

Every CAN controller maintains two counters purely in hardware: the Transmit Error Counter (TEC) and Receive Error Counter (REC). These increment when the node detects an error while transmitting or receiving, and decrement on successful frames — so a node with an occasional error on an otherwise healthy bus stays well within normal operating range. The increment amounts differ by error type and by whether the node was transmitting or receiving at the time (ISO 11898-1 specifies the exact values); the important practical point is that the counters track a pattern of errors, not a single glitch.

The Three Fault-Confinement States

The progression exists specifically so that a node with a real, sustained fault stops being able to interfere with the healthy nodes on the bus — error-passive already limits its ability to disrupt traffic, and bus-off removes it from the bus altogether rather than letting it keep consuming bus bandwidth with failed transmission attempts.

The ISO 11898-1 Bus-Off Recovery Sequence

Once a node enters bus-off, ISO 11898-1 defines a specific recovery condition: the node must observe 128 occurrences of 11 consecutive recessive bits on the bus before it's permitted to return to error-active state. This is a deliberately conservative requirement — it confirms the bus has been quiet and healthy for a sustained period before letting the previously-faulty node back on, rather than letting it rejoin the instant the bus looks momentarily clear.

Whether this sequence runs automatically or requires firmware to trigger it depends on the specific CAN peripheral and its configuration:

• Automatic recovery mode, where supported, has the controller silently count the required recessive-bit sequences and re-enter error-active state on its own once satisfied — no interrupt or firmware action is required beyond having enabled the mode at initialisation.
• Manual recovery, on peripherals or configurations that don't support automatic recovery, requires firmware to detect the bus-off condition (via a status register flag or dedicated interrupt) and explicitly reset and re-initialise the CAN peripheral to resume communication.

Check the specific MCU's reference manual for which mode applies and whether it's configurable — do not assume a node will silently reappear on the bus after a fault clears. For the STM32-specific configuration of these bits on the FDCAN peripheral, see How Do You Configure the STM32 FDCAN Peripheral?.

Common Root Causes of Bus-Off

• Missing or incorrect termination. The single most common cause. A bus without the correct 120 Ω termination at both physical ends reflects signal energy, corrupting frames intermittently — often working at low bit rates or short cable runs on the bench, then failing once deployed with longer cabling or added nodes.
• Bit-rate or bit-timing mismatch. A node configured for a different bit rate, or with a sample-point position that doesn't match the rest of the network, generates a steady stream of bit and CRC errors that will eventually push it (and potentially other nodes reacting to its errors) into bus-off.
• Wiring faults. An open circuit on CAN_H or CAN_L, a short between them, or a short to ground/supply produces sustained bus errors visible to every node, not just the faulty one — in this case, multiple nodes may go bus-off simultaneously, which is itself a useful diagnostic clue pointing at the physical bus rather than a single node's firmware or transceiver.
• A faulty transceiver. A transceiver with a damaged driver stage or a marginal receiver threshold can corrupt its own transmissions or misinterpret the bus state, generating errors that push the node itself into bus-off while the rest of the network stays healthy.
• Electrically noisy environment exceeding the design margin. In automotive and industrial environments, transient noise (relay switching, motor drive PWM, ESD events) can occasionally push error counters up even on a correctly wired bus; a design with inadequate shielding, grounding, or transceiver ESD protection will see this far more often than the fault threshold was intended to tolerate.

Practical Examples

A production batch of industrial sensor nodes on a shared CAN bus works reliably in the lab but reports a node going silent in the field after a few days of runtime. Investigation shows the node's TEC was climbing steadily during periods when a nearby variable-frequency drive was active — the transceiver's common-mode noise rejection margin was inadequate for the site's electrical environment. The node was frequently cycling through error-passive into bus-off and (because automatic recovery was enabled) silently recovering, which meant the field symptom was intermittent packet loss rather than a permanently dead node — a pattern that would have been invisible without deliberately logging TEC/REC values and bus-off event counts, not just checking whether the node was currently on the bus.

A vehicle prototype's CAN network intermittently loses one ECU after key-on. The ECU's firmware doesn't implement bus-off recovery at all — a design oversight assuming the peripheral would recover automatically, when in fact this particular MCU's CAN controller requires an explicit software reset after bus-off. Once triggered, the node stays permanently off the bus until power-cycled, even though the underlying wiring fault (a loose connector, intermittently open) had already cleared itself. Adding an explicit bus-off interrupt handler that resets and re-initialises the peripheral resolves the permanent-loss symptom, though the underlying connector issue still needs a hardware fix.

Design Considerations

• Always implement explicit bus-off detection and recovery in firmware, even if the peripheral supports automatic recovery. Confirm the specific mode is actually enabled rather than assuming a default, and add logging so a bus-off event is visible in diagnostics rather than only manifesting as "the node stopped responding."
• Log TEC/REC trends, not just the current bus-off/error-passive/error-active state. A node that's cycling repeatedly between error-passive and error-active without ever reaching bus-off is already telling you about a marginal fault — catching this before it escalates to full bus-off is far easier than diagnosing an intermittent field failure after the fact.
• Rate-limit or count repeated bus-off recovery attempts. If a node re-enters bus-off within a few frames of recovering, the underlying fault is still present — treat repeated rapid bus-off cycles as a persistent hardware fault to flag, not a transient condition to silently retry forever (see the FAQ above).
• Verify termination and bit timing first when diagnosing a new bus-off report. These two causes account for the large majority of bus-off field reports and are the fastest to rule out with a multimeter (termination resistance) and a protocol analyser or oscilloscope (bit timing, sample point).
• Zeus Design's embedded firmware team implements CAN bus drivers with robust error handling and bus-off recovery for automotive and industrial embedded products.

Common Mistakes

• Assuming the CAN peripheral will always recover from bus-off on its own. Automatic recovery is a configurable mode on many peripherals, not a universal guarantee — verify the specific setting for the MCU in use rather than discovering the gap in the field.
• Treating bus-off as a single-node problem when multiple nodes go bus-off together. Simultaneous bus-off across several nodes points at a shared physical-layer fault (termination, wiring, a single node's transceiver corrupting the whole bus) rather than independent firmware bugs in each node.
• Silently retrying recovery without logging or rate-limiting. A firmware loop that resets the CAN peripheral every time bus-off is detected, without tracking how often it's happening, turns a diagnosable persistent fault into an invisible one — the system appears to "self-heal" every time while the underlying problem never gets fixed.
• Debugging bus-off purely from the error counters without checking the physical layer first. TEC/REC values tell you a fault is occurring, not what it is — termination, bit timing, and wiring integrity should be the first things checked before assuming the fault is in application logic or message scheduling.