CAN troubleshooting
Expected CAN communication disappears, arrives irregularly, or becomes corrupted only under particular operating conditions. This guide helps establish whether the issue is in the observed traffic, CAN or CAN-FD interpretation, a network gateway path, or the recording workflow.
Start the diagnostic workflowObservable symptoms
A message visible during normal operation is absent during specific events or intervals in a CAN dump, BLF recording, or ASC recording. Compare the same message ID before and during the failure to distinguish a missing frame from a missing recording interval.
Timestamp intervals for an expected CAN message increase, become irregular, or stop altogether. This differs from a consistently configured message with a stable period and helps separate timing disruption from incorrect signal decoding.
The CAN frame remains present, but its payload or decoded signal values change unexpectedly during the failure. Comparing raw frames with the DBC helps distinguish a communication problem from a DBC interpretation mismatch.
Traffic remains visible on one part of the vehicle network while messages expected through a network gateway are absent on another path. This points toward path-specific behavior rather than a complete loss of all CAN communication.
Traffic appears incomplete or corrupted when the observed communication includes CAN-FD behavior but the analysis setup treats it as CAN, or when the reverse interpretation is used. Repeating the observation with the intended protocol interpretation helps separate configuration from vehicle behavior.
Possible causes
Vibration, temperature, harness movement, a damaged connector, or unstable termination can change impedance or continuity only under certain operating conditions. Correlate the first missing or erroneous frame with CANH/CANL waveform quality and the physical stimulus rather than relying on decoded data alone.
Differences between CAN and CAN-FD payload or data-phase behavior can make valid traffic appear corrupted, incomplete, or absent to an incompatible observation setup.
A network gateway may stop forwarding, delay, or conditionally forward traffic on the path where the failure is observed while communication remains present elsewhere.
The vehicle may continue communicating while the recording contains a gap, dropped observation interval, or inconsistent timestamps. This can resemble a missing CAN message unless the recording continuity is checked against other evidence.
An incorrect or incomplete DBC can make an existing frame appear to contain invalid values or can cause the analysis to focus on the wrong message and signal. The raw CAN frames must be checked independently of decoded results.
A brief supply drop, ground offset, transceiver disable, thermal fault, or ECU reset can stop transmission while the rest of the network remains active. Measure supply and ground and record controller or transceiver state through the same failure window.
Ordered investigation
Use the problem description to record the vehicle condition, communication path, expected message or signal, first observed failure, and whether the failure recovers. This narrows later comparisons without assuming that the reported missing communication is the root cause.
Inspect the BLF recording, ASC recording, or CAN dump around the failure window. Compare timestamp continuity and the presence of unrelated CAN traffic before concluding that the expected message stopped on the vehicle.
Compare frame IDs, timestamps, payload lengths, and payload bytes during a healthy interval and a failed interval. This separates an absent frame from a present frame with an unexpected payload or a decoding issue.
Determine whether the affected traffic is CAN or CAN-FD and whether the analysis setup treats it accordingly. This can rule out an observation mismatch, but it cannot establish that the vehicle network is healthy.
During the original vibration, temperature, load, or operating condition, monitor ECU and interface power and ground while observing CANH/CANL with an appropriate differential probe. Inspect wiring, connectors, termination, edge quality, and controller state at the first disturbance.
Compare traffic on the relevant sides of the network gateway, where those observations are available, and correlate the change with the failure window. If traffic exists before the gateway but not after it, the path requires gateway or system-owner investigation.
Repeat the operating condition while recording the affected traffic. For larger datasets, use CANalyzer, CANoe, or python-can to correlate timestamps and message presence; use ISO-TP or J1939 interpretation only when the problem description identifies those traffic types.
Verification gates
Read timestamps immediately before, during, and after the reported failure in the BLF recording, ASC recording, or CAN dump, and compare them with other traffic in the same interval.
Timestamps progress continuously and other CAN traffic remains observable through the failure window.
A gap or broad loss of traffic may indicate the recording or acquisition workflow rather than a vehicle-side missing message; repeat the capture and inspect the CAN interface path.
Count the expected CAN frame by ID across a healthy interval and the failure interval, then compare the time between consecutive occurrences.
The frame remains present with timing consistent with the expected behavior in both intervals.
A frame that is absent or irregular requires comparison with upstream traffic, network gateway behavior, and the operating condition; it does not alone identify the failing component.
With the network safely de-energized, compare CANH-to-CANL resistance with the network design while moving the suspect harness and connectors through the condition associated with the failure.
Resistance and continuity remain stable and agree with the installed termination design throughout the controlled movement or temperature condition.
Repair the affected terminator, branch, harness, or connector and repeat the original operating condition before changing software configuration.
Compare the protocol type assumed by the observation workflow with the protocol represented by the recorded traffic, including payload behavior where available.
The analysis interpretation matches the observed CAN or CAN-FD traffic consistently across the failure window.
An interpretation mismatch can produce apparent corruption or missing traffic; correct the analysis setup and repeat the comparison before escalating the vehicle behavior.
Compare the expected message on the available sides of the network gateway during matching timestamps and operating conditions.
The message is present on both relevant paths, or the documented path behavior explains its absence.
Presence before the gateway and absence after it focuses investigation on gateway forwarding or system integration; absence before the gateway shifts attention to the source path or acquisition evidence.
Measure ECU and interface supply voltage and ground offset while monitoring transceiver enable, controller state, and CANH/CANL waveform quality through the failing interval.
Power and ground remain within approved limits, the transceiver stays enabled, and differential edges settle cleanly before the sample point.
Investigate the power feed, ground path, transceiver control, physical bus segment, or interference source that changes with the operating condition.
From evidence to action
If recording continuity, CAN versus CAN-FD interpretation, or DBC decoding is responsible, correct the applicable workflow, repeat the recording, and document the affected messages and signals in the engineering analysis or CAN decoding results.
If repeated evidence identifies a harness, connector, terminator, transceiver, power, ground, or CAN interface fault, repair that boundary and repeat the same vibration, temperature, load, and operating condition while recording controller state and CANH/CANL waveform quality.
If traffic is present before a network gateway and absent after it, the gateway owner or system integrator must investigate forwarding conditions and timing. Validate the correction on both paths rather than only at the source.
If raw frames are present but interpretation is inconsistent, reconcile the DBC with the intended messages, signals, scaling, and nodes. Re-run decoding and retain the comparison as part of the engineering analysis.
FAQ
Diagnostic support
For difficult intermittent CAN cases, an independent engineering analysis can correlate recordings, raw frames, DBC decoding, and gateway observations into actionable findings.