CAN troubleshooting
The vehicle or CAN recording shows error frames, rising controller error counters, or a node entering bus-off. This guide helps narrow whether the instability is associated with CAN communication, CAN-FD behavior, message configuration, network interaction, or the recording and analysis path.
Start the diagnostic workflowObservable symptoms
A CAN dump, ASC recording, BLF recording, CANalyzer view, or CANoe trace contains error frames interleaved with otherwise expected traffic. Compare their timestamps with nearby frame activity to distinguish recurring bus instability from an isolated event.
The problem description or controller evidence reports a bus-off event, after which expected CAN traffic from the affected node is absent or changes. Distinguish this from a missing CAN message by checking whether the node reports a controller state transition.
Controller error counters rise during a reproduction interval, potentially followed by error frames or bus-off. A counter increase tied to specific traffic is stronger evidence of communication instability than a message absence observed without controller evidence.
The failure appears when a particular CAN or CAN-FD message group, recording segment, or network interaction is present. Compare an affected interval with a quiet interval to determine whether the failure is traffic-dependent or present continuously.
Possible causes
Missing or incorrect termination, excessive stub length, damaged twisted-pair wiring, or a high-resistance connector can create reflections and edge distortion. These physical faults can produce bit, form, or CRC errors, drive controller error counters upward, and eventually force a node bus-off.
An unpowered or intermittently powered node, a transceiver that is disabled or damaged, or excessive ground offset can prevent correct dominant and recessive levels. Compare ECU and interface supply voltage, ground reference, transceiver enable state, and CANH/CANL waveforms during the first error event.
An incorrect nominal bit rate, sample point, synchronization setting, or oscillator assumption causes a controller to sample valid edges at the wrong time. Confirm the active controller configuration against the network definition before changing message or application configuration.
A Classical CAN participant can respond with errors when it encounters CAN-FD frames, while incorrect nominal or data-phase timing and transmitter-delay compensation can destabilize only the faster phase. Correlate the error type and CANH/CANL waveform with FDF and BRS activity.
A faulty or misconfigured node can dominate the bus, transmit with incompatible timing, or repeatedly retransmit unacknowledged frames. Isolate participants only under an approved vehicle-safe procedure and compare the controller error code before and after each controlled change.
An interface operating in listen-only mode, a dropped recording interval, or incorrect error-frame import can make the evidence disagree with the actual controller state. Cross-check the same interval with controller status and an independent capture before assigning a vehicle fault.
Ordered investigation
Use the problem description to record the reproduction conditions, affected node if known, first observed error, bus-off timing, and expected behavior. This establishes the interval to inspect and prevents a missing message from being treated as a controller error.
Inspect the CAN dump, ASC recording, or BLF recording for error frames, bus-off evidence, and controller error-counter changes. If only an expected message is absent, classify that separately as a possible missing-message problem rather than concluding that CAN bus errors are present.
Compare timestamps immediately before and after each error with the surrounding CAN and CAN-FD traffic. Check whether the event is associated with ordinary CAN traffic, CAN-FD traffic, J1939 activity, or ISO-TP segmentation; this rules out unrelated intervals but does not alone identify the responsible node.
With the network safely de-energized, verify the expected end-to-end termination and inspect harness and connector continuity. During operation, measure ECU and interface supply and ground, then inspect CANH and CANL with an appropriate differential probe for correct dominant levels, ringing, or edges that cross the sample point late.
Review the same interval in CANalyzer or CANoe and, where appropriate, process the recording or CAN dump with python-can. Agreement across independent analysis paths increases confidence in the recorded event; disagreement points to recording, import, or interpretation differences that must be resolved first.
Compare traces with and without the traffic or node interaction that precedes the errors, including network gateway and higher-layer activity where present. This can narrow the responsible communication path, but it does not prove a hardware or software root cause without further vehicle or supplier evidence.
Document the reproduction conditions, timestamps, error evidence, controller state, relevant DBC interpretation, and comparison traces as an engineering analysis. Provide the package to the vehicle, supplier, or OEM team when the failure depends on an unavailable node, network gateway, or implementation detail.
Verification gates
Read the timestamp of the first error frame or bus-off event and compare it with the preceding and following CAN traffic in the recording.
The event has a clear timestamp and a reproducible surrounding traffic interval.
Unclear timing prevents reliable correlation; verify the recording, import path, and problem description before drawing a bus conclusion.
Compare the reported controller error counters and bus-off state with the error frames in the same interval.
Controller evidence and recorded error activity agree in time or are explicitly identified as separate observations.
The event may be a missing-message or analysis problem rather than a confirmed controller-level CAN error; inspect the source of each observation.
Identify whether the affected interval contains CAN-FD traffic and compare it with intervals containing only CAN traffic.
The traffic mode associated with the failure is known, or no mode-specific association is found.
Review the CAN-FD handling and communication configuration before assigning the failure to another cause.
De-energize the network using the approved procedure and measure resistance between CANH and CANL at the diagnostic point, then compare it with the network design and installed terminators.
The measured resistance agrees with the network design; a conventional high-speed CAN bus with two 120-ohm end terminators measures approximately 60 ohms.
Inspect terminators, connectors, branches, and harness continuity before repeating powered communication tests.
Use a suitable differential oscilloscope probe at the affected node and bus access point to compare dominant and recessive levels, edge timing, ringing, and common-mode movement during the first error.
The differential waveform reaches valid levels with clean edges and settles before the configured sample point without excessive ringing.
Locate the physical segment, transceiver, termination, or grounding condition that changes the waveform before changing DBC or application logic.
Measure ECU and measurement-interface supply voltage and ground offset through the failing condition while monitoring transceiver enable and controller state.
Supply and ground remain within the approved limits and the transceiver stays enabled throughout the reproduction.
Repair the power, ground, connector, or transceiver-control issue and repeat the original load and operating condition.
From evidence to action
Correct confirmed wiring, connector, termination, topology, transceiver, supply, or grounding faults. Repeat the original load and operating condition while checking CANH/CANL waveform quality and controller error state rather than validating only on a quiet bus.
If errors correlate with CAN-FD activity, review the involved CAN-FD handling and configuration across the communicating and analysis paths. Re-test with the same traffic conditions rather than relying only on a quiet-bus result.
If a node or network gateway consistently precedes the event, provide the timestamped evidence to the team responsible for that implementation. The resolution may require a vehicle, supplier, or OEM change when the responsible node or gateway cannot be modified locally.
If physical measurements are healthy but controller evidence shows sampling or acknowledgement faults, align nominal bit rate, sample point, synchronization settings, operating mode, and recovery behavior with the approved network configuration, then reproduce the first error interval.
FAQ
Diagnostic support
Need a defensible CAN bus error investigation? An independent automotive software engineer can turn recordings, CAN dumps, problem descriptions, and DBC data into focused engineering analysis and repeatable diagnostic workflows.