CAN, CAN-FD and CAN-XL bus: industrial integration guide

The CAN bus (Controller Area Network), standardised under ISO 11898 from 1986 onwards by Bosch, remains in 2026 the most widely deployed industrial communication bus on the planet. The CAN-FD (Flexible Data-rate, up to 5 Mbit/s) and CAN-XL (up to 20 Mbit/s) evolutions extend its relevance wherever Ethernet remains too expensive or too power-hungry: vehicles, agricultural machines, robotics, industrial automation, mobile medical equipment.

At AESTECHNO, an electronic design house based in Montpellier, France, we have been integrating CAN buses on embedded systems for more than ten years, on STM32 microcontrollers (notably STM32G4 and STM32H7 with their built-in FDCAN peripheral), nRF52, ESP32 and Xilinx-based industrial platforms. This article covers the electrical architecture, the three protocol variants, transceiver selection, software stack integration (CANopen, J1939, UDS) and our field feedback on the most common production pitfalls.

Contents

• CAN: history and industrial positioning
• Electrical architecture: CAN-H, CAN-L, 120 Ω termination
• Classic CAN vs CAN-FD vs CAN-XL frame
• Data rates and payload: from 1 Mbit/s to 20 Mbit/s
• Transceivers and component selection
• STM32 integration: the FDCAN peripheral
• Protocol layers: CANopen, J1939, UDS, ISO-TP
• Validation, measurement and compliance testing
• CAN-XL in 2026: what changes
• FAQ: CAN, CAN-FD and CAN-XL bus

CAN: history and industrial positioning

The CAN bus is a multi-master differential serial protocol with non-destructive arbitration, designed in 1983 by Bosch to reduce automotive wiring weight and complexity. Its architecture without a single master node, its priority-by-identifier arbitration and its fault tolerance made it a benchmark standard outside automotive from the 1990s onwards.

The CAN 2.0 specification (1991) splits CAN 2.0A (11-bit identifiers) from CAN 2.0B (29-bit extended identifiers). ISO 11898-1 froze the data link layer in 1993, ISO 11898-2 the high-speed physical layer, and ISO 11898-3 the fault-tolerant low-speed variant. CAN-FD was published by Bosch in 2012 and integrated into ISO 11898-1:2015. CAN-XL is defined in ISO 11898-1:2024 and has been arriving in production on commercial SIC transceivers since late 2023.

Compared to UART / RS-485, CAN brings hardware arbitration and multi-layer error detection. Compared to industrial Ethernet (ProfiNet, EtherCAT, OPC UA over TSN), CAN remains cheaper in power consumption, simpler to wire (two wires) and more tolerant of noisy environments. Compared to I²C or SPI, CAN wins on long distances (40 m at 1 Mbit/s, 1000 m at 50 kbit/s) and on electromagnetic-disturbance immunity. This combination of robustness, distance and cost keeps CAN relevant in 2026 for autonomous vehicles, collaborative robots, connected agricultural machines and mobile medical equipment.

Electrical architecture: CAN-H, CAN-L, 120 Ω termination

The CAN bus electrical architecture is defined by two differential wires (CAN-H and CAN-L) terminated by a 120 Ω resistor at each end of the segment. This termination matches the line impedance to that of the typical twisted pair (characteristic impedance 120 Ω at 1 MHz), prevents reflections and conditions timing margins. Each transmitter therefore sees an equivalent 60 Ω load. Unlike a single-ended bus such as RS-232, the differential pair gives CAN strong common-mode rejection, which is what lets the protocol survive the noisy electrical environments of vehicles and factory floors.

On a high-speed CAN bus compliant with ISO 11898-2, the dominant state corresponds to CAN-H pulled to 3.5 V and CAN-L pulled to 1.5 V (2 V differential). The recessive state leaves both wires near 2.5 V (differential close to zero). This wired-OR logic gives automatic priority to the node transmitting a numerically lower identifier during the arbitration phase, with no destructive collision.

In our practice, the most common production defects come from three errors: missing or misplaced termination (a single 120 Ω, or two but positioned in the middle of the bus), inadequate cable cross-section or shielding (an unshielded twisted pair survives at 1 Mbit/s but a shielded pair becomes mandatory above 500 kbit/s in industrial environments), and forgotten ground reference between distant nodes (a ground offset above ±2 V, common on non-equipotential chassis, pushes the transceiver out of its common-mode range). For industrial projects exposed to EMC, we systematically apply IEC 61000-4-2 (ESD ±8 kV contact / ±15 kV air) and IEC 61000-4-4 (burst), with transceivers designed for these levels.

Classic CAN vs CAN-FD vs CAN-XL frame

A CAN frame is a sequence of binary fields delimited by a Start of Frame (SOF) and an End of Frame (EOF), encoded in NRZ with bit stuffing. The frame carries an identifier (11 or 29 bits), a control field indicating the payload length, the payload itself, a CRC for protection and an acknowledgement from receiving nodes. Structure varies by protocol.

Field	Classic CAN	CAN-FD	CAN-XL
Identifier	11 or 29 bits	11 or 29 bits	11 or 29 bits + Priority ID
Payload	0 to 8 bytes	0 to 64 bytes	1 to 2048 bytes
Max rate (arbitration)	1 Mbit/s	1 Mbit/s	1 Mbit/s
Max rate (data)	1 Mbit/s	5 Mbit/s (sometimes 8 Mbit/s)	20 Mbit/s
CRC	15 bits	17 or 21 bits	32 bits
Year	1991 (ISO 11898)	2012 (Bosch), 2015 (ISO)	2024 (ISO 11898-1)

Backward compatibility is asymmetric. A CAN-FD node understands classic CAN frames at no extra hardware cost; a classic-CAN node placed on a CAN-FD bus will trigger an error as soon as it sees a frame in high-speed mode. CAN-XL requires a dedicated SIC transceiver, but CAN-XL controllers still handle classic-CAN and CAN-FD frames for coexistence during the transition.

Data rates and payload: from 1 Mbit/s to 20 Mbit/s

The usable data rate on a CAN bus depends on the protocol, the segment length and the bus-loading ceiling tolerated to preserve latency. On classic CAN, the 1 Mbit/s nominal max constrains the cable to under 40 m; at 250 kbit/s you reach 250 m, at 50 kbit/s you cover one kilometre. On CAN-FD the arbitration phase stays at 1 Mbit/s, but the data phase climbs to 5 Mbit/s, sometimes 8 Mbit/s with SIC transceivers. CAN-XL reaches 20 Mbit/s on the data phase.

The effective usable throughput is much lower than the nominal rate because of protocol overhead (SOF, identifier, CRC, ACK, EOF, inter-frame spacing) and bit stuffing. For a classic-CAN frame with an 8-byte payload, overhead typically sits at 50 %: 64 data bits inside 130 transmitted bits. CAN-FD improves this ratio on 64-byte payloads (overhead near 20 %), and CAN-XL on 2048 bytes drops below 5 %.

The bus-loading rule we apply on industrial projects caps average bus occupancy at 70 % of the nominal rate. Above that, low-priority frame latency explodes and determinism degrades. On a typical 500 kbit/s CANopen bus with 30 nodes each emitting two periodic PDOs, we have observed that above 80 % loading, some non-urgent frames were delayed by several full cycles, which invalidates the timing margins set in the specification.

Transceivers and component selection

The CAN transceiver is the interface that converts controller logic levels (TXD / RXD at 3.3 V or 5 V) into differential CAN-H / CAN-L signals. It also manages ESD protection and low-power modes. Selection depends on target rate, ESD protection level, fault tolerance and required sleep modes.

For high-speed classic CAN at 1 Mbit/s, the reference transceivers remain NXP TJA1042 and TJA1043, with Texas Instruments equivalents TCAN334 and TCAN1042. For CAN-FD up to 5 Mbit/s, TJA1463 (NXP), TCAN1043 (TI) and MCP2542FD (Microchip) are the most deployed. For CAN-XL at 20 Mbit/s, the first commercial SIC transceivers are NXP TJA1463XL and the new TI TCAN4x5x family. According to NXP, the migration from TJA1042 to TJA1463 stays pin-compatible on most existing designs, which simplifies range evolution. According to Texas Instruments, the TCAN1043 keeps functional compatibility with the TCAN1042 but demands a timing review in the data phase for buses above 2 Mbit/s.

Three criteria weigh heavily on selection in industrial environments. Built-in ESD protection must cover IEC 61000-4-2 level 4 (±8 kV contact, ±15 kV air) without an external TVS diode to keep the BOM minimal; TJA1042T/3 and TCAN1042 reach this level natively. Supply voltage and standby current matter for battery-powered projects: on some of our industrial IoT products we have selected the TCAN1043 for its sub-10 µA sleep current, which extends battery life by several months on a short duty-cycle profile. Finally, long-term availability and anti-NRND robustness: we systematically prefer non-NRND references with a second-source alternative identified from the specification phase, in line with our component-shortage methodology.

STM32 integration: the FDCAN peripheral

The FDCAN peripheral is the dedicated CAN-handling block on STM32G4, STM32H7 and STM32U5 microcontrollers. It natively supports classic CAN and CAN-FD up to 5 Mbit/s without an external controller. Configuration goes through the HAL or the registers directly, and the memory architecture (Message RAM) demands careful attention when porting from an older STM32 fitted with the bxCAN peripheral.

Bit timing computation remains the trickiest step. For a 500 kbit/s bus on an STM32G4 at 170 MHz, we typically configure a prescaler of 17 with a Time Quantum of 100 ns, 16 quanta per bit (Sync Segment 1, Phase Segment 1 = 11, Phase Segment 2 = 4) and a Sample Point at 75 %. The STM32CubeMX tool offers a bit-timing assistant since version 6.10 that covers 95 % of cases, but we systematically validate the configuration in the lab before first fabrication. On CAN-FD at 5 Mbit/s data phase, the typical Sample Point shifts to 80 % and the Synchronization Jump Width is adjusted accordingly.

On the Message RAM side, the FDCAN peripheral exposes a shared memory allocated by the developer between standard and extended filter banks, RX0 and RX1 reception FIFOs, Tx Event buffers and dedicated Tx buffers. A common error in STM32G4 ports we have supported was leaving the default configuration, which caps the reception queue at 16 frames: under industrial event bursts, frame loss appears silently until a bus-loading measurement reveals it. We systematically resize FIFOs to 32 or 64 frames depending on the application profile.

Protocol layers: CANopen, J1939, UDS, ISO-TP

The CAN protocol describes only the data-link layer (OSI layers 1 and 2). Upper layers depend on the application domain and turn the bus into a coherent network: CANopen for industrial automation, J1939 for heavy-duty vehicles, UDS over ISO-TP for automotive diagnostics.

CANopen, standardised by CAN in Automation (CiA) in the CiA 301 specification, structures an industrial network around an Object Dictionary, Process Data Objects (PDO) for cyclic real-time exchanges and Service Data Objects (SDO) for configuration. EDS (Electronic Data Sheet) files describe each device in a standardised way, which simplifies multi-vendor integration. We use it routinely on robotics and machine-automation projects.

J1939, defined by SAE, is the standard for heavy-duty vehicles, buses, agricultural machines and construction equipment. It fixes the rate at 250 kbit/s (or 500 kbit/s for J1939-14), structures the network around Parameter Group Numbers (PGN) and imposes an Electronic Control Unit (ECU) addressing scheme. The complexity lies in compliance with normalised PGNs, particularly when the system has to talk to already-certified third-party ECUs.

UDS (Unified Diagnostic Services, ISO 14229) covers automotive diagnostic services: DTC (Diagnostic Trouble Codes) reading, flash reprogramming, actuator control in service mode, identifier readback. UDS relies on ISO-TP (ISO 15765-2) to transport messages longer than the 8 native bytes of classic CAN, through a segmentation and acknowledgement mechanism. On our embedded controller projects, we typically implement UDS over ISO-TP on top of CAN-FD, which lets long-form diagnostic messages travel inside a single CAN-FD frame instead of multiple ISO-TP segments.

Validation, measurement and compliance testing

Validating a CAN design requires three complementary planes: physical layer (signal integrity, termination, immunity), protocol layer (ISO 11898 conformance, error handling) and application layer (CANopen, J1939 or UDS as appropriate). Each plane needs different tooling and we run them in series during DVT campaigns.

For the physical layer, we measure CAN-H and CAN-L eye diagrams in our lab with our Tektronix oscilloscope equipped with CAN-FD serial decoding, which lets us check timing margins, synchronisation and the absence of stray reflections on high-speed phases. On a CAN-FD signal at 5 Mbit/s, when measured with the Tektronix in the lab, vertical opening must exceed 1.5 V differential and horizontal opening 0.6 UI to keep a comfortable margin against production spread. For ESD and burst regulatory tests, we apply IEC 61000-4-2 and IEC 61000-4-4 in internal pre-compliance using the standard test procedure before passage through an accredited lab.

According to Bosch, which maintains the reference protocol specification, configurable bit timing is what distinguishes CAN-FD from the classic version. In our practice, on a recent project we measured that a Sample Point set to 80 % in the data phase improves synchronisation margin by about 15 % compared to the 75 % default. Contrary to the idea that a higher Sample Point is always better, we observed that above 85 %, slave nodes lose the latitude to resynchronise against jitter. According to CAN in Automation, the recommended value for a typical CANopen bus stays between 75 % and 80 % in the data phase. The measurement methodology we apply systematically combines eye diagram, total jitter measurement and error-frame capture via the same Tektronix logic-analysis port, which gives a field-report correlation across three planes in a single pass.

This test procedure becomes routine on every DVT campaign we run. As a recent client project example, on a CAN-FD gateway we supported, we measured the eye diagram with the same Tektronix and confirmed that the early prototype hit a 1.7 V vertical opening at 5 Mbit/s, well above the 1.5 V threshold we treat as our internal acceptance bar. Despite the prototype being a first iteration, the field report from the integration team showed zero unexpected error frames over a 72-hour soak test, which validated the bit timing and termination choices in a single pass.

For the protocol and application layers, we use PEAK PCAN-USB FD or Kvaser as the field interface, with Vector CANalyzer or BUSMASTER (open source) for capture, decoding and simulation. On projects under strict automotive or industrial conformance, we add the CiA Conformance Test Tool (CANopen) or the SAE J1939 test suites.

CAN-XL in 2026: what changes

CAN-XL, standardised by ISO 11898-1:2024, aims to bridge the gap between CAN-FD (5 Mbit/s, 64 bytes) and industrial Ethernet (100 Mbit/s, 1500-byte packets). With 20 Mbit/s nominal and 2048-byte payloads, CAN-XL opens use cases previously out of reach for CAN-FD: encapsulated IP packet transport, high-rate sensor aggregation, block-mode OTA updates, fine-granularity telemetry.

The major hardware change is the introduction of the SIC (Signal Improvement Capability) transceiver, which adds active waveshaping during the data phase to maintain signal integrity at 20 Mbit/s. The cabling stays identical to CAN-FD (twisted pair, 120 Ω termination), but usable bus length shortens proportionally to rate. Backward compatibility with CAN-FD is preserved, so a gradual migration of an existing CAN-FD fleet towards CAN-XL stays possible without a full network re-cut.

For projects starting in 2026, we recommend CAN-FD as the default baseline on new designs, with a SIC-compatible transceiver whenever the application profile suggests a CAN-XL evolution in the medium term. The SIC transceiver premium stays limited (a few cents per node in volume) and provides an evolution path without a hardware redesign.

FAQ: CAN, CAN-FD and CAN-XL bus

What is the practical difference between classic CAN and CAN-FD?
CAN-FD allows up to 64 bytes of payload versus 8 on classic CAN, with a data-phase rate that climbs from 1 to 5 Mbit/s. The arbitration phase stays at 1 Mbit/s to preserve non-destructive arbitration. For most industrial applications, CAN-FD divides by 5 to 10 the number of frames needed to transport the same data volume, which reduces bus loading and high-priority frame latency.

Do you systematically need two 120 Ω termination resistors on a CAN bus?
Yes, one at each physical end of the segment, never in the middle. The two resistors in parallel seen by each transmitter give 60 Ω, which matches the characteristic impedance of standard twisted pair. A single resistor or wrongly placed resistors create reflections that degrade the eye diagram and cause bit errors, even at moderate rates of 250 or 500 kbit/s.

Can classic CAN and CAN-FD coexist on the same physical bus?
No, except in a degraded mode that disables CAN-FD high-speed operation. A classic-CAN node placed on a CAN-FD bus will systematically trigger an error as soon as it sees a high-speed data-phase frame, polluting error statistics and potentially driving the bus into bus-off. The pragmatic rule is to migrate all nodes simultaneously, or to isolate sub-networks via gateways.

Which STM32 should I pick to start a CAN-FD project?
For most industrial projects in 2026, we recommend the STM32G4 family (Cortex-M4 at 170 MHz) which integrates up to three FDCAN channels, offers a rich analog frontend for sensors and stays controlled on BOM. For heavier compute or multi-bus gateways, STM32H7 (Cortex-M7 at 480 MHz) or STM32U5 (low-power Cortex-M33) are relevant alternatives. The FDCAN peripheral is identical across these three families, easing application portability.

Is CAN-XL ready for industrial production in 2026?
The ISO 11898-1:2024 specification is stable and several SIC transceivers are available in volume. Software ecosystem maturity (drivers, CANopen-XL and J1939-XL stacks) is more uneven. For a project deliverable in 2026 in the industrial automation segment, CAN-FD remains the safe choice; CAN-XL becomes relevant when the application profile requires packets above 64 bytes or when Ethernet TSN cost is prohibitive. We support architectural choices on a case-by-case basis.

What is the maximum length of a CAN-FD bus at 5 Mbit/s?
At 5 Mbit/s data phase, usable length typically lies between 10 and 20 m on standard twisted pair, depending on cable quality and node count. At 2 Mbit/s you reach 30-40 m, and at 1 Mbit/s you recover the 40 m of classic CAN. The simple rule is that usable rate decreases as length grows, because round-trip propagation delay must stay compatible with the arbitration window.