CAN Bus Diagnostics

This page is a practical guide for diagnosing CAN bus problems: a completely dead bus, a device that does not transmit (no TX), a device that receives nothing (no RX), sporadic errors, and bus-off conditions.

It is organised by the tools you have available:

• No tools at all — configuration and wiring checks
• Multimeter — resistance and voltage measurements
• Oscilloscope — signal quality, baud rate, ACK behaviour
• CAN analyzer / USB interface — error counters, traffic analysis

Work through the sections in order — most problems are found without ever touching an oscilloscope.

Related pages: IOcan pinout, Wiring concepts, Technical specifications, Working with the CAN bus.

How a healthy CAN bus behaves

Understanding five facts about CAN solves the majority of problems:

1. CAN is a differential pair. CANH and CANL carry mirrored signals and must be a twisted pair. CANH connects to CANH, CANL connects to CANL, on every node.
2. Every node must use the same baud rate. A single node at the wrong baud rate does not just stay silent — it actively destroys traffic by sending error frames.
3. The bus needs exactly two 120 Ω terminators, one at each physical end. Measured between CANH and CANL this reads ~60 Ω.
4. A transmitter needs a listener. Every CAN frame must be acknowledged (ACK) by at least one other node. A lone device on a bus cannot successfully transmit — it will retransmit the same frame forever and raise errors. "My device doesn't transmit" is very often really "nobody acknowledges".
5. All nodes need a common ground reference. CAN tolerates only a limited ground offset between nodes (roughly −2 V to +7 V common-mode). Modules grounded to different points with a large offset will produce errors even though the differential wiring is correct.

Electrical states

Bit time and bus length

Typical automotive rates: 500 kbit/s (powertrain), 100–125 kbit/s (body/comfort), 250 kbit/s (J1939 / commercial).

Symptom quick reference

Step 1: checks without any tools

Do these before reaching for any instrument — they find most faults.

Configuration

• Baud rate identical on every node, including your analyzer.
• Classical CAN vs CAN FD — an FD frame on a classical bus is treated as an error by classical controllers. If any node does not support FD, run the whole bus in classical mode.
• Correct channel — with multiple CAN interfaces (IOcan has four) it is easy to configure CAN1 but wire CAN3. Confirm the configured channel matches the connector pins (IOcan pinout).
• Termination setting — where termination is software-switchable (as on IOcan), confirm it is enabled/disabled to match the physical position of the device on the bus.
• Power and wake-up — IOcan requires KL15 (ignition) to activate CAN communication. A missing KL15 wire looks exactly like a dead CAN bus. See Wiring concepts.

Wiring and topology

• Check connector seating; give each CAN wire a gentle pull test at the connector — a terminal that backs out of the housing is a classic intermittent fault.
• Verify CANH↔CANH, CANL↔CANL at every joint. On OEM harnesses check the wire colours against documentation rather than assuming.
• Topology must be a single line with nodes on short stubs — not a star. Keep stubs as short as possible, well under 30 cm at 500 kbit/s.
• Count the terminators: exactly two, one at each end of the line. Remember that many devices (ECUs, analyzers, IOcan) have built-in termination that may be active.
• Use twisted pair for all CAN runs and keep them away from ignition leads, injector wiring and alternator cables.

Isolation by elimination

If the bus has several nodes, disconnect all of them except two and test. Re-add nodes one at a time. A single faulty node (wrong baud, defective transceiver, shorted internally) can take down an entire bus, and this finds it with no tools at all.

Multimeter diagnostics

A basic multimeter diagnoses most wiring faults.

Resistance checks (power off)

Power the system off and measure resistance between CANH and CANL at any convenient point (the OBD connector pins 6 and 14 work well on a vehicle bus — see OBD pinout):

Then check each line against ground and battery:

Finally verify end-to-end continuity of each line across the harness, and wiggle the harness while measuring — a reading that jumps around indicates a bad crimp or chafed wire. Note the wiki-wide advice: use properly crimped terminals, not solder (Technical specifications).

Voltage checks (power on)

Power the system on and measure each line to ground (DC range):

A multimeter cannot see individual frames — it only shows averages. If the voltages look plausible but communication still fails, move to an oscilloscope or analyzer.

Ground offset check

Measure DC voltage between the ground pin of one module and the ground pin of another (e.g. IOcan KL31 vs the ECU ground). More than a few hundred mV of offset — or a reading that jumps when loads switch — indicates a poor ground connection that can corrupt CAN traffic even though the data wiring is fine.

Oscilloscope diagnostics

An oscilloscope shows what the multimeter cannot: signal shape, timing and per-frame behaviour. Even a cheap single-channel scope is enough for most checks; two channels are better.

Setup

• Channel 1 → CANH, Channel 2 → CANL, both referenced to system ground.
• 1–2 V/div, timebase around 10 µs/div at 500 kbit/s.
• Trigger: falling edge on CANL or rising edge on CANH, level ~2.8 V.
• With two channels, display the math function CH1 − CH2 — this is the differential signal the transceivers actually see (~0 V recessive, ~2 V dominant), and it makes ground noise invisible, so problems that remain in the math trace are real.

What healthy traffic looks like

• CANH pulses up from 2.5 V toward 3.5 V; CANL pulses down from 2.5 V toward 1.5 V — clean mirror images of each other.
• Differential amplitude ~2 V during dominant bits.
• Edges are clean with only minor overshoot; the signal settles well within a bit time.

Verify the baud rate

Find the narrowest pulse in a frame — that is one bit time:

If this does not match the configured rate on your receiving device, you have found the problem. This is the definitive test for "device X says the bus is silent but device Y says it is transmitting".

Termination problems on the scope

Check the ACK behaviour (diagnosing "no TX")

This is one of the most valuable scope checks. When a node transmits, it sends one bit near the end of the frame (the ACK slot) as recessive, and any receiving node overwrites that bit as dominant.

• Frame acknowledged: frames appear once, bus returns to idle between different frames.
• Frame not acknowledged: you see the same frame repeating back-to-back forever — the transmitter is retrying because no one ACKs. Causes: no other powered node on the bus, all other nodes at a different baud rate, or your analyzer is in listen-only mode (listen-only never ACKs).

Error frames

An error frame is a burst of 6 or more consecutive dominant bit times that interrupts a frame, after which traffic resumes. Occasional error frames during startup are normal; continuous error frames mean a node is actively rejecting traffic — almost always a baud-rate/FD mismatch or a signal integrity problem.

Noise and ground offset

• Both lines moving together (common mode) is normally harmless — the differential trace stays clean. If the common-mode excursions exceed roughly −2 V to +7 V, transceivers start missing bits: fix grounding.
• Spikes on the differential trace correlated with ignition/injector/alternator events indicate coupling — reroute the CAN pair, restore twisting, or increase separation from noisy wiring.

CAN analyzer diagnostics

A USB CAN interface (or IOcan itself — it provides candump-compatible CAN output over USB, see Technical specifications) gives per-frame and per-error visibility.

First connection rules

• Set the analyzer to the bus baud rate; when unsure, try listen-only mode at each standard rate (500k, 250k, 125k, 100k, 1M) until frames decode cleanly. Listen-only guarantees your guessing cannot disturb the bus.
• Remember that listen-only does not ACK. If the analyzer is the only other node, the device under test will show TX failures even though your wiring is perfect. Switch to normal mode for two-node bench tests.
• Check whether the analyzer has internal termination and count it toward your two terminators.

Error counters and bus states

Every CAN controller maintains a transmit error counter (TEC) and receive error counter (REC). With SocketCAN-compatible tools:

ip -details -statistics link show can0   # bus state, TEC/REC, error stats
candump -e can0,0:0,#FFFFFFFF            # dump traffic including error frames

A TEC that climbs while you watch means every transmission is failing (usually ACK missing); a REC that climbs means received frames are corrupt (usually baud mismatch or signal integrity).

Useful traffic-level checks

• Bus load — a classical 500 kbit/s bus above ~80 % load will delay or starve low-priority IDs.
• Duplicate IDs — two nodes transmitting the same CAN ID with different data cause bit errors that look like random corruption. Every transmitted ID must have exactly one owner.
• Log long-term for intermittent faults and correlate error bursts with events (engine start, fans, gear changes, hitting bumps).

Symptom walkthroughs

Completely dead bus

Device does not transmit (no TX)

1. Is there a second, active node? A lone CAN node cannot complete a transmission — no ACK means endless retransmission and rising TEC. Connect a second real node, or an analyzer in normal (not listen-only) mode.
2. Same baud rate on both? A wrong-rate partner never ACKs either.
3. Is the device in bus-off? Check error counters/status if available; power-cycle to reset and watch whether TEC climbs again.
4. On a scope: if you see the same frame repeating back-to-back, wiring is fine and TX works — the problem is purely the missing ACK (points 1–2). If you see nothing at all on the pins, check channel assignment, device power/wake-up (KL15), and the harness between device and bus.

Nothing is received (no RX)

1. Confirm the bus actually carries traffic at the point where the device connects (scope or analyzer). If not, work the dead-bus flow first.
2. Verify baud rate — measure the real bit width on a scope, or try listen-only rates on an analyzer. Mismatch is the number-one cause of "silent" receivers, and it usually also produces error frames that disturb the rest of the bus.
3. Check for swapped CANH/CANL at the device connector. A swapped pair inverts the differential signal — the node receives nothing on an otherwise perfect bus.
4. Check the harness leg to this device — a broken single line or a terminal backed out of the connector kills RX while the rest of the bus works.
5. Check software — correct CAN channel selected, no receive filters discarding the IDs you expect, and for IOcan check timeout behaviour of CAN inputs (Working with the CAN bus).

Intermittent errors

Intermittent faults are almost always physical. In rough order of likelihood:

Error counters and bus-off

A device that "worked and then went silent" has usually gone bus off: its TEC exceeded 255 due to accumulated failures and the controller removed itself from the bus. The counter values are the diagnosis:

• TEC climbing → its transmissions fail: missing ACK, wrong baud on partner nodes, or its own signal is corrupted (wiring on its stub).
• REC climbing → what it hears is corrupt: baud mismatch or bus-wide signal-integrity problems.

Fix the underlying cause first — a device that recovers from bus-off onto the same faulty bus will simply go bus-off again.

Common mistakes checklist

IOcan-specific notes

• Four independent buses — double-check that the configured bus number matches the CANxH/CANxL pins actually wired (CAN Gateway Pinout).
• Software-switchable 120 Ω termination on every network — enable it only when IOcan sits at a physical end of that bus, and remember it when counting terminators with the multimeter.
• KL15 is required to activate CAN communication — on the bench, feed KL15 from your supply along with KL30/KL31.
• Built-in sniffer — IOcan exposes candump-compatible CAN traffic over USB, so it can serve as the analyzer for its own buses; see Technical specifications.
• CAN input timeouts — configure TimeoutMode on safety-relevant CAN inputs so a silent bus is detected instead of holding stale values (Working with the CAN bus).