THE BUS
Differential signaling buys margin, not invulnerability.
Classical high-speed CAN uses a differential pair, typically called CAN_H and CAN_L. Receivers care primarily about the voltage difference between those conductors, which helps reject noise coupled similarly into both wires. That is useful in vehicles and industrial systems where motors, alternators, contactors, long harnesses, and ugly ground environments exist.
But the transceiver still has a common-mode operating range. Shift both conductors far enough relative to a node's local reference and the differential signal can be perfectly shaped yet unreadable or electrically abusive. Ground offsets, shield currents, wiring faults, and mixed power domains therefore still matter.
TERMINATION
The two resistors are not optional decorations at the ends of the drawing.
A high-speed CAN trunk is normally terminated at its physical ends to match the cable's characteristic impedance closely enough to control reflections. Missing, duplicated, misplaced, or incorrect termination can produce ringing, reduced amplitude, timing-dependent corruption, and systems that work at one bitrate or harness length and fail at another.
With power removed, a healthy two-end network using nominal 120-ohm terminations is often expected to measure roughly 60 ohms across CAN_H and CAN_L because the two terminations appear in parallel. That is a useful field check, not a proof of health. Parallel branches, split termination, active circuitry, or nonstandard physical layers can change the measurement.
The important question is physical topology: where are the actual electrical ends of the trunk, and what is connected there?
STUBS
A CAN schematic can hide a transmission-line problem inside a neat branch.
Long stubs create additional reflection paths. At low bitrates and short harnesses the system may tolerate generous branching. As edge rate, bitrate, and physical extent increase, those branches become harder to ignore.
This is why a star made from ordinary wire can behave beautifully on a bench at 125 kbit/s and become unreliable after migration to a faster network or longer harness. The protocol did not suddenly become moody. The electrical network changed relative to the signal timing.
Document trunk length, stub lengths, transceiver locations, connector transitions, and termination. “CAN bus” is not a topology description.
ARBITRATION
Losing arbitration is normal. Treating it as a fault is not.
CAN uses dominant and recessive bit behavior so multiple nodes can begin transmitting without ordinary destructive collision. During arbitration, a node that sends recessive but observes dominant recognizes that a higher-priority identifier has won and stops transmitting without flagging a bus error.
That property gives CAN deterministic priority behavior under contention, but it also creates system-level consequences. High-priority traffic can delay low-priority traffic indefinitely if the bus is badly scheduled. The electrical network can be healthy while application deadlines still fail.
Bus utilization therefore belongs in timing analysis. Priority is a resource allocation policy disguised as an identifier field.
ERROR DETECTION
CAN spends a lot of protocol machinery noticing when reality disagrees.
Controllers detect several classes of error, including bit monitoring, stuffing violations, frame-format problems, acknowledgement failures, and CRC failures. An error-active node can signal an error flag that invalidates the current frame so the message can later be retransmitted.
This is one reason CAN is resilient. Corrupted frames are not casually handed upward as valid application data. But repeated retransmission has a cost: bandwidth disappears, latency rises, and a pathological node can consume network time until fault-confinement rules reduce its influence.
FAULT CONFINEMENT
The protocol keeps score.
CAN controllers maintain transmit and receive error counters. Persistent error behavior moves a node through states commonly described as error active, error passive, and, for sufficiently severe transmit error accumulation, bus off.
That progression is not merely an implementation curiosity. It is diagnostic evidence. A rising transmit error counter suggests a different class of problem than a node that mostly accumulates receive errors. A bus-off event means the protocol has deliberately stopped that controller from transmitting so it cannot continue damaging traffic.
Software should record these transitions. If firmware automatically resets the controller and erases the counters without leaving a trace, it converts useful protocol evidence into folklore.
BUS OFF
Recovery policy belongs above the controller.
A bus-off controller has reached a state where it no longer participates normally in transmission. Hardware and standards define conditions for recovery, but application policy still has to decide whether automatic re-entry is safe.
On a logging node, automatic recovery may be reasonable. On a steering, braking, propulsion, or industrial safety function, immediately rejoining after repeated physical-layer faults may be the wrong choice. Re-entry can require fault logging, a quiet period, self-test, operator acknowledgement, or escalation into a degraded mode.
The principle is the same as watchdog design: reset is a mechanism. Recovery is a system decision.
ACK ERRORS
A lonely transmitter can look broken while doing exactly what the protocol says.
CAN frames include an acknowledgement mechanism. A transmitter that sees no valid acknowledgement from another participant can report an ACK error and retry. That can happen because the network is physically broken, because no other node is present, because every listener is configured incorrectly, or because bit timing prevents them from decoding the frame.
Bench-testing one node on an otherwise empty bus can therefore generate alarming counters that are not evidence of transceiver failure. Always reproduce the intended network condition before diagnosing from error flags alone.
BIT TIMING
Nominal bitrate equality is not the whole timing contract.
Nodes must sample each bit within a compatible timing window despite oscillator tolerance, propagation delay, transceiver delay, cable length, and resynchronization behavior. Two devices can both claim “500 kbit/s” while incompatible timing parameters or clock accuracy make the real network marginal.
Problems often appear at temperature extremes, long harness length, different transceiver families, or after replacing a crystal with a lower-cost oscillator. If errors correlate with distance or temperature, capture the waveform and inspect configured bit timing rather than merely confirming the nominal bitrate string.
TRANSCEIVERS
The CAN controller and CAN transceiver are different failure domains.
The protocol controller handles frames, arbitration, CRC, and error state. The transceiver connects that logic to the differential electrical bus. Many systems also include standby pins, slope control, wake behavior, undervoltage handling, dominant-timeout protection, ESD protection, and fault-tolerant states.
A controller may insist it is transmitting while the transceiver is disabled. A transceiver can be held in standby by a GPIO default. Partial power can make the bus pins behave differently than expected. A damaged transceiver can dominate one conductor while the MCU remains perfectly healthy.
Measure TXD, RXD, CAN_H, CAN_L, transceiver supply, and mode pins together when the failure refuses to fit the software story.
FIELD METHOD
Diagnose the bus in layers.
1. Measure termination with power removed. Confirm the physical network resembles the intended topology.
2. Scope CAN_H and CAN_L. Inspect differential amplitude, symmetry, ringing, and common-mode movement.
3. Record controller error counters and state. Error warning, passive, and bus-off transitions are evidence.
4. Check utilization and arbitration. A healthy physical layer can still miss deadlines under priority starvation.
5. Correlate faults with nodes. Remove branches or power nodes selectively and observe whether error behavior follows.
6. Check transceiver mode and power. A sleeping transceiver can impersonate a dead network.
7. Test recovery deliberately. Short the bus temporarily in a controlled lab setup, disconnect termination, force bus-off, and verify that logging and recovery policy behave as designed.
BOTTOM LINE
CAN is robust because it exposes failure, not because failure disappears.
Use the protocol's error machinery as instrumentation. Combine it with waveform measurement, topology knowledge, transceiver state, and application timing. A network that automatically retransmits everything can remain superficially functional while latency and error counters quietly announce that the physical layer is dying.
Robustness is the ability to fail legibly and recover deliberately.
SOURCE TRAIL
Technical starting points.
Texas Instruments — Introduction to the Controller Area Network (CAN)
Microchip — CAN bus diagnostic counters
Kvaser — CAN error handling and confinement