CAN Bus Communication Diagnosis — Understanding and Testing Vehicle Network Communication
Written by Anthony Calhoun, ASE Master Tech A1-A8
Modern vehicles are rolling computer networks. The engine control module does not talk directly to the transmission control module the way two people might call each other on the phone. Instead, every module on the vehicle shares a common communication bus — a pair of wires where all modules broadcast messages simultaneously and every other module listens. When that network breaks down, you can end up with a car that cranks but will not start, a transmission stuck in limp mode, stability control disabled, or a cluster full of warning lights — all from a single wiring fault or one failed module pulling the network offline.
This article covers how CAN bus networks are built, how they work at the electrical level, how to read U-codes intelligently, how to use a scope at the DLC, and how to work through a methodical diagnosis from the scan tool all the way down to isolating a corrupted module or broken wire. This is working technician information — no fluff, no theory for the sake of theory.
CAN Bus Architecture — The Different Networks on a Single Vehicle
Most technicians know there is a CAN bus, but the important detail is that most vehicles have several separate CAN networks running simultaneously, each operating at a different speed and serving a different purpose.
High-Speed CAN — 500 kbps (Powertrain)
This is the fastest and most critical bus on the vehicle. The engine control module, transmission control module, and any module that needs real-time powertrain data lives here. The 500 kbps data rate means it can push a new message onto the bus every two milliseconds. Fuel injector timing, torque requests, throttle position — all of it moves fast because the powertrain demands it. This bus connects to DLC pins 6 (CAN-H) and 14 (CAN-L).
Medium-Speed CAN — 250 kbps (Chassis)
ABS modules, electronic stability control, active suspension, electric power steering, and four-wheel drive control typically live on the medium-speed bus. Still fast enough for real-time control, but separated from the powertrain bus to limit interference and manage traffic load. On many vehicles, pins 3 and 11 at the DLC carry this bus, though this varies by manufacturer.
Low-Speed CAN — 125 kbps (Body and Comfort)
Body control modules, HVAC, instrument clusters, door modules, and other comfort systems that do not require fast real-time data use the low-speed bus. On some GM vehicles, pins 1 and 9 at the DLC carry this bus. The lower speed reduces electrical noise sensitivity and is sufficient for functions like window control or seat adjustment.
LIN Bus — Sub-Network for Simple Devices
Local Interconnect Network runs under a CAN node as a single-wire sub-bus. A body control module acting as a LIN master controls simple slave devices like power mirror motors, rain sensors, seat position motors, and sunroof controls. LIN runs at 20 kbps or less. These devices do not need their own CAN transceiver — they just respond to commands from the LIN master. When a mirror stops folding in or a seat motor quits, the fault is often in the LIN network or the slave module, not the main CAN bus.
FlexRay — High-Bandwidth for Safety-Critical Systems
Some European vehicles, particularly BMW, Mercedes-Benz, and Audi models with advanced active chassis systems, use FlexRay on the suspension and steering networks. FlexRay runs at up to 10 Mbps and operates on a time-triggered protocol rather than the priority-based arbitration CAN uses. Active roll stabilization and steer-by-wire systems need the deterministic timing FlexRay provides. Diagnosing FlexRay requires manufacturer-specific scan tools — generic scope testing at the DLC will not reach these networks on most vehicles.
Automotive Ethernet — Emerging for ADAS
Advanced driver assistance systems generate enormous amounts of data — cameras, radar, LiDAR, and sensor fusion processors need bandwidth that CAN cannot deliver. 100BASE-T1 and 1000BASE-T1 automotive Ethernet is appearing in newer vehicles specifically for ADAS backbone communication. This is single-pair Ethernet over an unshielded twisted pair and operates at 100 Mbps or 1 Gbps. Standard CAN diagnostic methods do not apply here. Diagnosing ADAS communication faults on these systems requires the OEM tool and an understanding of the vehicle's specific Ethernet topology.
How CAN Communication Actually Works
CAN is a message-based protocol, not an address-based protocol. There is no source address or destination address inside a CAN frame. Instead, every module broadcasts messages identified by an arbitration ID. Every other module on the bus receives every message and decides whether that message is relevant to it. The instrument cluster picks up engine speed messages from the ECM because the cluster is programmed to watch for that specific arbitration ID — the ECM does not target the cluster specifically.
Arbitration and Priority
When two modules try to transmit at the same moment, the bus arbitration system resolves the conflict without collision. The module with the lower arbitration ID wins. It continues transmitting while the higher-ID module backs off and waits. This is why critical powertrain messages get low arbitration IDs — they win bus access over lower-priority body messages every time.
Error Detection
CAN has several built-in error detection mechanisms. CRC (cyclic redundancy check) catches data corruption in transit. Acknowledgment bits confirm that at least one other module received the message correctly. Bit stuffing catches synchronization errors. When a module detects an error, it sends an error frame onto the bus — an intentional protocol violation that signals all other nodes that a bad message just passed. Every module counts transmit errors and receive errors separately. When error counts climb past a threshold, a module moves from error-active to error-passive mode. If errors keep accumulating, the module goes bus-off — it completely disconnects from the bus and stops transmitting or receiving until it resets.
Bus-Off State
A module in bus-off state is not dead — it is protecting the network. A single module with a shorted CAN transceiver that is actively corrupting every message it sends will trigger error frames from every other module on the bus. If the corrupting module goes bus-off, the rest of the network recovers. If it keeps recovering automatically and going bus-off again in a loop, you will see intermittent communication faults across the entire bus. This behavior is a strong clue that one module has a bad transceiver.
U-Code Diagnosis — Reading Network Fault Codes Intelligently
U-codes are the scan tool's way of reporting communication failures. Unlike P-codes or B-codes which report system faults, U-codes report that a module could not talk to another module. Understanding what each U-code means and which module stores it tells you a lot before you pick up a meter.
Common U-Codes and What They Point To
| U-Code | Meaning | Starting Point |
|---|---|---|
| U0073 | Control module communication bus off | Bus-level problem — scope the bus, check termination |
| U0100 | Lost communication with ECM/PCM | ECM power/ground, ECM CAN transceiver, wiring to ECM |
| U0101 | Lost communication with TCM | TCM power/ground, TCM CAN transceiver, wiring to TCM |
| U0121 | Lost communication with ABS control module | ABS module power/ground, medium-speed bus wiring |
| U0140 | Lost communication with BCM | BCM power/ground, low-speed bus wiring |
| U0155 | Lost communication with instrument panel cluster | Cluster power/ground, bus wiring to cluster |
The key diagnostic strategy with U-codes is cross-referencing which modules store them. If only the ECM stores a U-code saying it lost communication with the TCM, the problem is likely specific to the TCM or its connection to the bus. If every module on the high-speed bus stores U0073 simultaneously, the entire bus went down — that points to a wiring issue (open, short, or termination fault) rather than a single module failure.
Always check U-codes in every module you can access, not just the module that triggered the MIL. Pull codes from the ECM, TCM, ABS, BCM, cluster, and any other accessible module. Map out which modules are storing faults about which other modules. The pattern tells the story.
DLC Pin Assignments — Know Your Test Points
The OBD-II DLC is your primary test access point for CAN bus diagnosis. Knowing which pins carry which buses lets you get scope leads on the right wires immediately.
| DLC Pin | Signal | Bus |
|---|---|---|
| Pin 6 | CAN-H (High) | High-speed CAN (500 kbps — Powertrain) |
| Pin 14 | CAN-L (Low) | High-speed CAN (500 kbps — Powertrain) |
| Pin 3 | CAN-H (Medium) | Medium-speed CAN (250 kbps — Chassis, some vehicles) |
| Pin 11 | CAN-L (Medium) | Medium-speed CAN (250 kbps — Chassis, some vehicles) |
| Pin 1 | Low-speed CAN or manufacturer-specific | Low-speed CAN (125 kbps — Body, some GM) |
| Pin 9 | Low-speed CAN or manufacturer-specific | Low-speed CAN (125 kbps — Body, some GM) |
| Pin 7 | K-Line / ISO 9141 | Older vehicles pre-CAN, some KWP2000 |
| Pin 4 | Chassis ground | Reference ground for testing |
| Pin 16 | Battery positive | 12V reference |
Verify pin assignments for the specific vehicle you are diagnosing using factory wiring data. On vehicles with a gateway module, some buses are not directly accessible at the DLC — they are routed through the gateway, which only exposes the bus the scan tool communicates on. On those vehicles, you need to back-probe at the module connectors to reach the isolated bus directly.
Oscilloscope Testing at the DLC
A scan tool that shows bus communication tells you something is working. A scope shows you the quality of the signal, whether there is noise, whether waveforms are distorted, and whether error frames are appearing. This is the difference between knowing the network is up and knowing the network is healthy.
Setting Up the Scope
Connect channel one to DLC pin 6 (CAN-H) and channel two to DLC pin 14 (CAN-L), both referenced to chassis ground at pin 4. Set time per division to approximately 500 microseconds to start — this gives you a readable view of individual CAN frames at 500 kbps. Set volts per division to 1V per division on each channel. Turn on ignition, or start the engine if you need network traffic to be active.
What a Healthy High-Speed CAN Waveform Looks Like
On a healthy high-speed CAN bus, both channels should idle at approximately 2.5 volts with the bus in its recessive state. When a module transmits a dominant bit, CAN-H rises to approximately 3.5 volts while CAN-L drops to approximately 1.5 volts simultaneously. The differential voltage between CAN-H and CAN-L during a dominant bit is approximately 2 volts. During a recessive bit, both lines return to 2.5 volts and the differential is zero. Clean waveforms show sharp, well-defined edges with consistent amplitude. The two channels should be mirror images of each other around the 2.5V center line.
What Faults Look Like on the Scope
- CAN-H shorted to ground: CAN-H sits at 0 volts or near ground instead of the 2.5V recessive level. The bus may still show activity on CAN-L but the differential is corrupted. U0073 will be widespread.
- CAN-L shorted to battery: CAN-L sits at 12 volts. The differential is inverted. No modules will communicate. All modules on that bus will store U-codes.
- CAN-H and CAN-L shorted together: Both lines sit at the same voltage — approximately 2.5 volts — and never move. No bus traffic at all. The two lines need to move in opposite directions to create the differential signal, and a short between them prevents that.
- Open CAN wire: One channel shows activity and the other is flat. The bus may still function if termination and the intact wire allow enough signal, but errors will be present and signal quality drops significantly.
- Bad termination: Waveforms look rounded or ringing rather than sharp square waves. The signal edges slope instead of stepping cleanly. You may see the waveform overshoot and bounce after each transition.
- Corrupted module transmitting: You will see random glitches, error frames (a sequence of six consecutive dominant bits), or waveform distortion during specific time windows. This is the hardest fault to catch without monitoring multiple sessions.
Network Topology — Star vs. Backbone
Not all CAN networks use the same physical layout. Understanding the topology determines where to test and what affects what else.
Backbone (Bus) Topology
In a backbone topology, all modules connect to a single continuous two-wire bus. Termination resistors sit at each end of the backbone — typically 120 ohms each, giving 60 ohms across the bus when measured with all modules disconnected and power off. An open anywhere in the backbone splits the bus into two isolated segments. Modules on one side of the break cannot communicate with modules on the other side.
Star Topology with Gateway Module
Many modern vehicles use a central gateway or a body control module that bridges multiple buses. Modules connect to the gateway in a star pattern rather than all sharing one continuous wire. The gateway translates messages between buses — a transmission control module on the high-speed powertrain bus can send torque information that the instrument cluster on the body bus receives, because the gateway translates and re-broadcasts relevant messages. When the gateway fails, you lose communication between buses even though each individual bus may still be functional. This explains why a gateway failure produces U-codes across nearly every system on the vehicle.
On star topology vehicles, resistance testing at the DLC may not give you the standard 60-ohm reading because the gateway module itself contains termination and the point-to-point connections do not add up the same way. Always pull the factory wiring diagram before interpreting resistance readings.
Common CAN Bus Problems
Module Not Responding
A module that was communicating and now is not has either lost power, lost ground, crashed its firmware, or failed internally. Start by verifying power and ground directly at the module connector with a voltmeter. Check every power feed pin — some modules have multiple power and ground inputs. A module that has full power and ground but still does not respond on the bus likely has an internal hardware failure. On some platforms, a module can be recovered with a reflash if it lost its programming, but a hardware failure — particularly a dead CAN transceiver — requires replacement.
Module Corrupting the Bus
This is the diagnostic nightmare. One module with a shorted internal CAN transceiver continuously drives the bus lines to a dominant state, blocking all other communication. Every module stores U-codes. The scope shows no clean traffic, just a flat line or a heavily distorted signal. The strategy is module isolation — disconnect modules one at a time until the bus comes back. When you disconnect the bad module, the remaining modules will immediately resume normal communication and the scope waveform will clean up. Identify which segment the bad module is on first using the scope and U-code pattern, then start isolating in that area rather than pulling connectors at random.
Wiring Faults
CAN bus wiring is twisted pair for a reason. The twist rate is specified by the manufacturer and is not arbitrary. Untwisting more than a few inches at a splice can increase noise susceptibility enough to cause intermittent faults. When splicing a CAN wire, maintain the twist as close to the splice as possible. Common wiring faults include chafed insulation causing CAN-H to CAN-L shorts, corrosion in a connector that creates resistance on one leg of the differential pair, and broken wires inside undamaged-looking insulation.
Termination Resistor Faults
High-speed CAN requires 120-ohm termination at each end of the bus. With both terminators in place and all modules disconnected, you read approximately 60 ohms across CAN-H and CAN-L. If you read 120 ohms, one terminator is missing or open. If you read 40 ohms, a third terminator has been added somewhere — this happens when someone installs an aftermarket trailer brake controller or other add-on that incorrectly terminates the bus. If you read near zero ohms, CAN-H and CAN-L are shorted together. Some modules contain the termination resistor internally — check the factory diagram before assuming a standard external terminator configuration.
Testing Methodology — Step by Step
- Scan all modules for U-codes. Pull codes from every accessible module. Note which U-codes appear in which modules. Map the communication failures. Determine which bus or buses are affected based on the module locations and their network assignments.
- Determine which modules are communicating. A scan tool that uses the CAN bus to communicate will only reach modules that are active. Note which modules respond to the scan tool and which are completely absent. Absent modules are either offline or off the bus entirely.
- Scope the DLC. Connect to pins 6 and 14 for the high-speed bus. Verify voltage levels and waveform quality. Determine if the bus has traffic at all, if the traffic is clean, or if there are error frames and distortion.
- Resistance test with ignition off. Disconnect the battery or use the DLC with the key off. Measure resistance between pins 6 and 14. Expected result for a healthy high-speed bus is approximately 60 ohms. Verify this against the factory specification for the specific vehicle — some architectures differ.
- Scope at module connectors. If the DLC scope shows a bus problem, move to the module connectors in the suspect area. Back-probe CAN-H and CAN-L at individual module connectors. This tells you which segment of the bus has the fault and narrows the physical location.
- Module isolation. If the bus is completely down or heavily corrupted, isolate modules by disconnecting them one at a time. Each time you disconnect a module, check the bus with the scope or a resistance test. When the bus recovers after a disconnection, the module you just unplugged is the problem.
- Verify power and ground on suspect modules. Before condemning a module, confirm it has proper voltage at every power pin and a clean ground at every ground pin. A module with a weak ground can exhibit intermittent communication faults that look like a failing CAN transceiver.
Post-Repair Verification
CAN bus repairs are not complete until you have confirmed the entire network is back to normal operation, not just the component you replaced.
After the repair, connect the scan tool and verify every module that should be present on the network is visible and communicating. On some scan tools you can run a network test that polls all known module addresses and reports which ones respond. Run this test and compare the results to the expected module list for that vehicle and option level.
Clear all U-codes from every module. Do not just clear the codes in the module that triggered the complaint — clear them everywhere. U-codes stored in secondary modules can trigger warning lights and DTCs of their own even after the primary fault is repaired.
Perform a complete drive cycle appropriate to the vehicle. For powertrain-related bus faults, this typically means running through all the enable criteria for the communication monitors. For body bus faults, exercise the affected systems — operate the windows, test the HVAC, verify the cluster displays correctly, and confirm that adaptive features like automatic headlights and rain-sensing wipers function normally.
After the drive cycle, reconnect the scan tool and check for any returning U-codes. An intermittent fault will often reappear during the drive cycle if it was not fully repaired. If codes return, the fault is still present and you need to continue diagnosis.
Verify all related systems function correctly. A CAN bus failure can cause a module to store a DTC or enter a reduced-function mode that does not automatically clear when communication is restored. Some modules require a drive cycle to exit learned fault states. Others may require a manual reset or module configuration procedure. Check for any remaining codes in every module, including active codes in systems that appeared unaffected — a missing network message during the failure event may have caused a secondary fault in a module that was working fine mechanically.
Final Notes for the Shop
CAN bus diagnosis is methodical work. The technicians who struggle with it are usually trying to skip steps — pulling modules before scoping the bus, or ordering parts based on a single U-code without mapping the full fault picture. The ones who get it right follow the data. U-codes point to a bus and a module. The scope confirms bus health. Resistance testing confirms the wiring. Module isolation finds the corrupting device. Every step builds on the last.
Invest in a scope if you do not have one. A basic two-channel scope capable of capturing CAN waveforms costs less than one misdiagnosed module replacement. Once you can see what the bus is actually doing, diagnosis becomes straightforward rather than guesswork.
Know your factory resources. Wiring diagrams, connector views, and the vehicle's specific bus topology are not optional for CAN diagnosis — they are required. The vehicle you are diagnosing may use a gateway that isolates bus segments, a non-standard termination configuration, or a proprietary bus assignment on the DLC pins. Factory data confirms what you are looking at before you commit to a test strategy.
The network is the nervous system of the modern vehicle. Understand how it is built, learn to read what the scope tells you, follow a structured approach, and CAN bus diagnosis becomes one of the more satisfying problems in the shop to solve.