How to Diagnose CAN Bus Issues: A Step-by-Step Guide

TL;DR

Short on time? Here is what you need to know before diving in.

• Two diagnostic areas: every CAN bus diagnosis starts at the physical layer (wiring and hardware) before moving to the protocol layer (messages and software).

• Three multimeter checks: termination resistance (~60Ω), line voltages (CAN High: 2.5–3.0 V, CAN Low: 2.0–2.5 V), and transceiver resistance to ground (should be megaohms or open).

• Know your error types: bit, stuff, CRC, form, and ACK errors each point to different root causes. A node’s error counters (TEC/REC) tell you how close it is to going bus-off.

• Three active CAN standards: CAN 2.0 (baseline), CAN FD (up to 64 bytes per frame, higher data rates), and CAN XL (up to 2048 bytes, up to 10 Mbit/s — ratified 2021). Your diagnostic tools must match the standard in use.

• Tools covered in this guide: multimeter, PCAN-USB with PCAN-View (free, PC-based), PCAN-Diag FD (handheld), and CAN data loggers for HIL testing and field failure reproduction.

In 1991, the Mercedes-Benz W140 was the first production vehicle to feature a CAN (Controller Area Network) based wiring system. By 2008, almost all passenger cars and light trucks sold in the U.S. used CAN bus networks.

Today, CAN bus remains the backbone of industrial and automotive communication — including EV battery management systems, motor controllers, and charging infrastructure — making diagnostics on CAN systems a vital skill for engineers.

Before CAN bus gained popularity, vehicle wiring harnesses could contain miles of copper wire, which significantly added to the cost and weight of the vehicle. CAN bus was originally designed to minimize copper wiring in automobiles by multiplexing electrical signals over a simple two-wire network. By using a high-speed twisted pair cable, the amount of wire necessary to allow sensors, actuators, and controllers to communicate was greatly reduced.

When performing a CAN network diagnosis, it’s important to evaluate two distinct areas:

• The physical CAN bus network (the wiring and hardware)
• The CAN protocol (the software used to pass messages)
  

What is a CAN Bus?

courtesy of CSS Electronics

CAN bus is a two-wire differential signaling network that communicates over a twisted pair: CAN High (CANH) and CAN Low (CANL). The voltage difference between the two lines carries the data — not the absolute voltage of either wire alone. This differential design makes CAN bus highly resistant to electromagnetic interference, which is why it performs reliably in noisy industrial and automotive environments.

CAN Bus Standards: CAN 2.0, CAN FD, and CAN XL

The CAN standard covers the physical and data link layers of the network. Three versions are in active use today.

CAN 2.0

Published in 1991, CAN 2.0 has two parts:

• Part A: standard format with an 11-bit identifier

• Part B: extended format with a 29-bit identifier

CAN 2.0 supports data frames up to 8 bytes and a single bit rate for the entire frame.

CAN FD (Flexible Data-rate)

Released in 2012, CAN FD increases effective data throughput by allowing longer data fields (up to 64 bytes per frame, compared to 8 bytes in CAN 2.0) and a higher bit rate during the data phase. CAN FD is now standard in many automotive and industrial applications where higher throughput is required.

CAN XL

Standardized by CiA (CAN in Automation) in 2021, CAN XL is the latest evolution of the standard. It supports data fields up to 2048 bytes per frame and data phase bit rates up to 10 Mbit/s — well beyond CAN FD. CAN XL is designed for next-generation applications in ADAS, EV architectures, and industrial automation where data density is a priority.

Diagnosing CAN XL networks requires tools that specifically support the standard. Check your analyzer’s specifications before starting a diagnosis on a CAN XL bus.

Think of the lower layer of CAN bus as bits transmitted at defined speeds on the wire itself. The standard in use determines how fast and how much data can travel per frame.

The CAN Protocols (Higher-Layer)

While the CAN standard defines the physical layer, a higher-layer protocol is required to manage communication messages on the CAN bus. The higher-layer protocol handles details such as node addresses, flow control, fragmentation of data messages larger than 8 bytes, and establishment of communication among other things.

Think of the higher-layer protocol as the way messages (data) are formatted, transmitted, and received. Common higher-layer protocols include:

• CANopen / CANopen FD — Industrial automation. CANopen FD extends CANopen for CAN FD networks.

• IEC 61375-3-3 — Use of CANopen in rail vehicles.

• DeviceNet — Industrial automation.

• EnergyBus — Battery–charger communication.

• ISOBUS — Agriculture.

• NMEA 2000 — Marine industry.

• SAE J1939 — In-vehicle network for commercial vehicles (buses and trucks).

• UDS (ISO 14229) — Unified Diagnostic Services; the dominant protocol for automotive ECU diagnostics and programming.

• OBD-II (ISO 15765-4) — On-board diagnostics over CAN; standard for emissions and vehicle health data across modern passenger vehicles.

All of these protocols communicate over the CAN bus physical layer

CAN Bus System Diagnostics: A Step-by-Step Guide

Diagnosing CAN bus problems can be challenging, but with the right approach, you don’t have to be highly technical to perform basic CAN bus diagnostics. Follow this sequence: start at the physical layer, escalate to protocol analysis when hardware checks out, and add logging when the problem is intermittent.

Step 1: How to Test CAN Bus at the Physical Layer

Most CAN bus issues stem from hardware failures. All modules on a network need four things: power, ground, a data connection, and proper configuration.

Use a multimeter to investigate these potential failure points.

1. Device Configuration

Make sure the baud rate of the CAN communications matches all other devices on the bus. A single device configured at the wrong baud rate will cause errors across the entire network.

2. Termination Resistance

A CAN bus must be terminated on both ends with a 120-ohm resistor to prevent signal reflections from interfering with data transmission. In some devices, the termination resistor is built in.

• Turn power off.

• Measure resistance between CAN High and CAN Low. The reading should be approximately 60 Ω (two 120 Ω resistors in parallel).

3. Voltages and Ground Connection

• Disconnect all CAN devices from the bus except the device being tested.

• Power on the device under test.

• Measure voltage between CAN High and Ground: should be between 2.5 and 3.0 Vdc.

• Measure voltage between CAN Low and Ground: should be between 2.0 and 2.5 Vdc.

• Turn power off.

• With the meter on the lowest resistance scale, measure the ground wire to earth ground. The reading should be less than 0.1 Ω.

4. Transceiver Resistance

You can test the CAN port on a device to check for damage. Damage from lightning or transients typically causes a short to ground on one or both CAN lines.

• Disconnect the device under test from the CAN bus.

• Make sure power is off to the device under test.

• Measure resistance from CAN High to Ground and from CAN Low to Ground. The result should be megaohms or open. A lower reading indicates a likely faulty transceiver.

CAN FD diagnostic note:

 

CAN FD networks switch to a higher bit rate during the data phase, which places stricter demands on cable quality, termination, and transceiver slew rate. At data rates above 1 Mbit/s, issues that would not affect CAN 2.0 — such as unterminated stubs, marginal termination, or excessive cable capacitance — can cause intermittent errors. If physical layer tests pass but CAN FD errors persist, use a CAN FD-capable oscilloscope or analyzer to check signal integrity at the data phase bit rate.

Step 2: Understand CAN Bus Error Types

Before reaching for a protocol analyzer, it helps to know what error types to look for. CAN defines five error types at the frame level. Understanding what each one points to saves time during root cause analysis.

Error counters matter. Every CAN node maintains a Transmit Error Counter (TEC) and Receive Error Counter (REC). As errors accumulate, a node transitions from error-active (normal operation) to error-passive (limited error signaling), and eventually to bus-off (the node removes itself from the bus entirely). If a node repeatedly drops off the network, check its error counters — a CAN analyzer will display these in real time.

Step 3: Troubleshooting the CAN Protocol

For complex communication issues, you need a CAN bus analyzer. These tools range from free software with basic functionality to full-featured hardware interfaces with detailed data and analysis.

Using a CAN Bus Analyzer (PC-Based)

A practical solution for CAN diagnostics is a USB to CAN bus adapter. In this example, we use the Peak System PCAN-USB adapter with their free Windows software for displaying CAN and CAN FD messages — PCAN-View. PCAN-View supports both CAN 2.0 and CAN FD networks.

Equipment needed:

• PCAN-View (free download) running on a laptop.

• PCAN-USB adapter to connect to and monitor the CAN bus network.

• At least one CAN device active on the network. CAN bus should be terminated with 120Ω resistors on each end.

The PCAN-USB plugs into a USB port on the laptop. Download and install the USB driver from PEAK.

One limitation of this method is that the data rate of the CAN network must be known before configuring the adapter. If the baud rate is unknown, the PCAN-Diag FD handheld unit can auto-detect it (see Step 4).

To start the connection to the CAN bus, click the link icon in the top left of the PCAN-View window. This brings up the configuration page. 

This brings up the configuration page. 

Select the correct bit rate from the dropdown. In this example, 125 kbps. 

Click OK — you should start to see packets arriving.

Here, we are seeing packets from CAN ID 0x01. PCAN-View monitoring and diagnostic capabilities include:

• Displays all received CAN messages with ID, Data Length, and data bytes in a list.

• Transmits data frames or Remote Request frames manually, on a timer, or as replies to incoming Remote Requests.

• Detects and displays Error Frames on the bus.

• Includes a Tracer (data logger) for recording and storing CAN bus traffic.

Step 4: Handheld CAN Bus Diagnostics

For more powerful troubleshooting — or when working on a live system in the field — handheld diagnostic units offer capabilities that PC-based setups cannot match.

PCAN MiniDIAG FD - Handheld Diagnostic Tool  SKU : GC-CAN-MINIDIAG-FD MPN : IPEH-003070	PCAN DIAG FD - Handheld Diagnostic Tool for CAN FD Networks SKU : GC-CAN-DIAG-FD MPN : IPEH-003069

An integrated handheld CAN diagnostics unit provides:

• Auto-detection of the CAN bit rate — no need to know the baud rate in advance.

• Bus load measurements displayed as a time diagram, with optional display of error frames.

• Termination resistance measurement while the system is running.

• Voltage measurement for all pins on the connected CAN bus.

•  

  Displays CAN messages received on the network.

• Transmit individual messages or full sequences; trace and play back CAN traffic using the internal memory.

• Integrated two-channel oscilloscope for visualization of CAN signals.

• Frame decoding from recorded packets to identify errors within the frame.

One of the biggest advantages of a handheld tool is that it analyzes the CAN bus at both the physical layer and the protocol level in a single device. That saves time and gets you to the source of the problem faster.

Step 5: Log CAN Bus Data

Real-time monitoring works well for problems that are actively present on the bus. Many CAN bus issues are intermittent, though — they surface under specific load conditions, timing sequences, or environmental factors that are difficult to reproduce on demand. That’s where CAN data logging comes in.

A CAN data logger captures all traffic on the bus over an extended period and stores it for offline analysis. Common use cases include:

• Hardware-in-the-loop (HIL) testing — log all CAN traffic during a full test cycle to verify system behavior against expected outputs.

• Field failure reproduction — capture the exact bus state before, during, and after a failure event to identify root cause.

• Production line validation — confirm that a completed assembly communicates correctly under real operating conditions.

When selecting a CAN data logger, verify that it supports the CAN standard your network uses (CAN 2.0, CAN FD, or CAN XL), has sufficient sample rate and storage for your data volume, and can be configured to trigger recording on specific message IDs or error conditions.

Browse Grid Connect’s CAN data logging products.

Frequently Asked Questions

What resistance should a CAN bus read?

With both termination resistors in place and power off, measuring between CAN High and CAN Low should give approximately 60 Ω. This is two 120 Ω resistors in parallel, one at each end of the bus. A reading significantly higher or lower indicates a missing, incorrect, or damaged termination resistor.

What voltage should CAN High and CAN Low read?

On a non-transmitting (recessive) bus, CAN High should measure between 2.5 and 3.0 Vdc relative to ground. CAN Low should measure between 2.0 and 2.5 Vdc relative to ground. During a dominant bit, CAN High rises to approximately 3.5 V and CAN Low drops to approximately 1.5 V.

How do I find the baud rate of an unknown CAN bus?

A handheld diagnostic unit such as the PCAN-Diag FD will auto-detect the bit rate. Some PC-based analyzers also include baud rate scanning. Standard CAN baud rates are: 10, 20, 50, 125, 250, and 500 kbps, and 1 Mbit/s.

What causes a CAN node to go bus-off?

When a node’s Transmit Error Counter (TEC) reaches 256, it enters bus-off state and removes itself from the network. This is typically triggered by repeated transmission failures — most often caused by a wiring problem, incorrect termination, or a faulty transceiver. The node can only recover with a hardware reset or a software-initiated recovery sequence.

What is the difference between CAN 2.0, CAN FD, and CAN XL?

CAN 2.0 (1991) supports up to 8 bytes per frame at a single bit rate. CAN FD (2012) supports up to 64 bytes per frame and can switch to a higher bit rate in the data phase. CAN XL (2021) supports up to 2048 bytes per frame and data phase bit rates up to 10 Mbit/s. All three share similar physical layer fundamentals but require tools that match the standard in use.

Do I need different tools for CAN FD vs. CAN 2.0?

For physical layer testing, standard multimeter procedures apply to both. For protocol-level analysis, your analyzer must support CAN FD to decode CAN FD frames correctly. The PCAN-USB adapter and PCAN-View both support CAN FD. For CAN XL, verify tool compatibility before starting diagnostics.

What is the difference between a PC-based analyzer and a handheld diagnostic unit?

A PC-based analyzer offers a full-featured software interface ideal for lab environments where you can connect a laptop. A handheld unit is self-contained, typically battery-operated, and better suited for field work or live system troubleshooting. Handheld units also auto-detect baud rates and can measure physical layer parameters without a separate multimeter.

Summary

CAN bus diagnostics follow a clear sequence. Start at the physical layer with a multimeter. Escalate to a protocol analyzer when hardware checks out but communication still fails. Add a handheld unit when you need portability or combined physical-and-protocol analysis in one device. Use a data logger when the problem is intermittent or when your test environment requires full traffic capture.

Understanding which CAN standard is on your bus — CAN 2.0, CAN FD, or CAN XL — matters before you start. The right tool depends on the right standard.

If you need help selecting the right diagnostic tool for your network, contact Grid Connect’s experts or browse our full CAN diagnostics catalog.