CONNECTIVITY

CAN Bus

CAN bus arbitration, dominant/recessive voltage levels, bit stuffing, frame structure, and error states. Interactive multi-node arbitration simulator, a full-frame walkthrough that animates every field (SOF, ID, DLC, data, CRC-15, ACK, EOF) on real CANH/CANL voltage waveforms, a CRC noise demo, and a fault-injection debug lab.

Reviewed 2026-08-228,147 words

The mode matrix: what every controller mode really controls

A CAN controller's operating mode is not a menu of unrelated features. Every mode is a combination of three switches: whether the transmitter may drive dominant bits onto the wire, whether the receiver is fed from the bus or internally from its own transmitter, and whether the acknowledge and error-signalling logic are allowed to act. Vendor names differ wildly, but any mode in any datasheet can be placed in that matrix, and once placed its behaviour is fully determined.

How it is built

Transmit path enable: may the node pull the bus dominant at all? If not, it can never send a frame, an error flag, or an acknowledge, and is electrically invisible.
Receive path source: does the protocol engine sample the real bus pin, or a loop from its own transmitter before the pin? This is the difference between an external and an internal loopback.
Acknowledge generation: may the node drive the dominant ACK slot for frames it received correctly? A node that cannot acknowledge is not a participant, only an observer.
Error signalling: may the node transmit an error flag when it detects a violation? A mode that suppresses this cannot disturb other traffic, which is exactly why diagnostic modes suppress it.
Error counters: TEC and REC may still count in a passive mode even when nothing is transmitted, which is what lets a listen-only node judge whether the bus is healthy.

Design procedure

Identify what the mode does to the transmit path first; that alone separates the diagnostic modes from the operational ones.
Then ask whether the node still acknowledges. A silent node that does not acknowledge cannot keep a two-node bus alive - the other transmitter will error out.
Then ask where receive data comes from. If it is internal, nothing you observe proves the transceiver or the wiring works.
Confirm whether the mode can be entered only from initialisation, which is the usual restriction, or changed on the fly.
Check whether leaving the mode needs a controller reset and resynchronisation to eleven recessive bits before transmission may resume.

Key terms

Dominant: Logical 0. An active drive that overrides any recessive driver on the bus; this asymmetry is what makes arbitration and error signalling work.
Recessive: Logical 1. The idle, undriven state held by the termination and the transceiver's bias network.
Protocol engine: The state machine doing bit timing, stuffing, arbitration, CRC and error management. The mode switches sit around it.
TEC / REC: Transmit and receive error counters. Their values place the node in error-active, error-passive, or bus-off.
Initialisation mode: The state after reset in which bit timing and filters may be written. Most controllers allow a mode change only here.

Worked example

Placing three common vendor names in the matrix:

  ST 'silent'             TX disabled, RX from bus, no ACK, no error frames
  Bosch 'bus monitoring'  the same thing, a different word
  NXP 'listen-only'       the same thing again

  ST 'loopback'           TX drives the pin, RX from the bus
  ST 'silent loopback'    TX blocked at the pin, RX internal

The three names in the first group are one mode. The two in the second differ
in exactly one switch, and that switch decides whether a passing test says
anything at all about your hardware.

Common pitfalls

Normal mode, and what a node must do before it may speak

Normal mode is full participation: the node transmits, receives, arbitrates, acknowledges other nodes' frames, signals errors, and runs its error counters. It is the only mode in which a node is a real bus member. Entering it is not instantaneous - after initialisation the protocol engine must first observe the bus idle before it is allowed to start transmitting.

How it is built

The controller leaves initialisation only after bit timing, the sample point, the synchronisation jump width, and the acceptance filters have been written.
It then waits for eleven consecutive recessive bits, the definition of bus idle, before it may begin a transmission.
Transmission begins with SOF, a dominant bit, and every node hard-synchronises its bit clock to that falling edge.
The node monitors what it is driving. Any mismatch outside the arbitration and ACK fields is a bit error.
Acceptance filters decide which received identifiers reach a receive FIFO. They never affect acknowledgement, which happens for every valid frame regardless of filtering.

Design procedure

Write the bit timing registers so the nominal bit rate and sample point match every other node on the bus, not merely something that seems reasonable.
Configure acceptance filters before leaving initialisation, or the first frames are lost or flood the FIFO.
Leave initialisation and wait for the hardware's own synchronisation indication rather than immediately queueing a transmission.
Queue a frame; hardware handles arbitration, stuffing, CRC, ACK checking, and automatic retransmission.
Check the transmit result. A completion means at least one other node acknowledged, which is real information about the bus.

Key terms

Bus idle: Eleven consecutive recessive bits. Both the condition to start transmitting and the recovery criterion out of bus-off.
SOF: Start of frame, one dominant bit. The hard synchronisation edge for every receiver.
Acceptance filter: A hardware mask and value pair deciding which identifiers are stored. Filtering is not a substitute for acknowledging.
Automatic retransmission: The default: a frame that lost arbitration or hit an error is re-queued by hardware with no software involvement.
Sample point: Where in the bit the level is read, as a percentage of bit time. Every node on a bus must agree closely.

Worked example

A successful transmit says more than it appears to:

  frame sent -> ACK slot read back dominant
     at least one other node received the whole frame, checked the
     CRC and drove the ACK bit, which means the wiring, both
     transceivers, the termination and the bit timing of at least
     two nodes are all correct

  frame sent -> ACK slot stays recessive
     nobody is listening, or nobody agrees with the CRC, or this
     node is alone on the bus; hardware retransmits and TEC climbs
     by 8 on every attempt

Common pitfalls

Listen-only, silent, and bus-monitoring mode

One mode with three names. The transmit path is disabled at the pin: the node never drives a dominant bit for any reason - not a data frame, not an error flag, not an acknowledge. It receives everything, runs its CRC and form checks, and updates its error counters, but is electrically invisible to every other node. This is the correct mode for a diagnostic tool, a bus logger, or automatic bit-rate detection.

How it is built

The transceiver's transmit input is held recessive, or the controller's internal transmit enable is removed, depending on the implementation.
The receive path is the real bus pin, so everything observed is genuine traffic rather than a local echo.
The receiver still detects stuff, form and CRC errors and still increments REC, which is precisely what makes bit-rate probing work.
No acknowledge is generated, so from the bus's point of view this node does not exist as a recipient.
Most controllers permit entry to this mode only from initialisation.

Design procedure

Enter initialisation, select listen-only, then leave initialisation as normal.
For automatic bit-rate detection, set a candidate bit timing and watch for received frames with no errors over a window covering several frames.
If REC climbs or nothing valid arrives, try the next candidate rate and repeat.
Once a rate produces clean reception, return to initialisation, clear listen-only, and rejoin as a full node.
For a permanent logger, simply remain in the mode - but only if at least two other nodes exist to acknowledge each other.

Key terms

Listen-only: The ISO name. Receives and analyses, never drives dominant.
Silent mode: ST's name for the same behaviour.
Bus monitoring: Bosch's name for the same behaviour, used in M_CAN documentation.
Bit-rate detection: Cycling candidate timings in listen-only until frames decode cleanly. Safe precisely because a wrong guess cannot disturb the bus.
Passive observer: Any node that receives without acknowledging. No transmitter counts it as a recipient.

Worked example

Automatic bit-rate detection, which is only safe because this mode cannot
disturb traffic:

  for rate in [1M, 500k, 250k, 125k, 100k, 50k, 20k]:
      enter init; set timing(rate); select listen-only; leave init
      observe for about 200 ms
      if frames_received > 0 and rec_is_stable:
          found = rate; break

Guessing wrong in normal mode would put the node on the wire transmitting
error flags at the wrong bit rate, corrupting every frame on a working bus.

Common pitfalls

Loopback modes: external, internal, and combined

Loopback feeds a node its own transmissions. In external loopback the frame is actually driven onto the wire and read back through the transceiver, so the whole physical path is exercised. In internal loopback - often called silent loopback or self-test - the transmit path is disconnected from the pin and the receiver is fed internally, so nothing reaches the bus. The distinction decides whether a passing test means anything about your hardware.

How it is built

External loopback: the transmit path drives the pin normally, the receive path samples the pin, and the node treats its own frame as received.
In external loopback the controller generates its own acknowledge internally, so no other node is needed for the transmission to complete.
Internal loopback: the transmit output is held recessive at the pin while the receiver is fed directly from the transmitter.
Internal loopback therefore works with the transceiver unpowered, the bus disconnected, and no termination fitted.
Both modes exercise bit timing, stuffing, CRC generation and checking, and the filter configuration.

Design procedure

Choose internal loopback to validate bit timing arithmetic and filter setup on a bench with no bus present.
Choose external loopback to additionally validate the transceiver, the board wiring, the termination, and the connector.
Transmit a frame whose identifier the acceptance filters accept, otherwise it is sent and discarded and the test proves less than intended.
Confirm the received identifier, DLC and payload match what was transmitted, not merely that a receive interrupt fired.
Return to initialisation and clear the mode before joining a live bus, since a node left in loopback acknowledges only itself.

Key terms

External loopback: Own frames go out on the wire and come back through the transceiver. Tests the physical layer.
Internal loopback: Own frames never leave the silicon. Tests the protocol engine only.
Self-test mode: Common vendor name for internal loopback, sometimes combined with self-acknowledge.
Self-acknowledge: The controller drives its own ACK slot so a loopback frame completes with no other node present.
Silent loopback: ST's combination of silent and loopback: internal loopback with the pin held recessive.

Worked example

What each mode actually proves, which is the entire reason to tell them
apart:

  internal loopback passes
     bit timing registers are arithmetically consistent
     stuffing, CRC, filters and FIFOs work
     transceiver UNTESTED, wiring UNTESTED, termination UNTESTED

  external loopback passes
     all of the above, plus the transceiver TX and RX paths, the
     board traces, the connector, and enough termination for the
     bus to return to recessive in time

  external fails but internal passes
     the fault is in the transceiver, its enable pin, or the wiring

Common pitfalls

Restricted operation mode

Restricted operation is a mode defined for CAN FD controllers in which the node receives data and remote frames normally and acknowledges them, but never transmits a frame of its own, never signals an error, and never sends an overload frame. It sits between listen-only and normal: unlike listen-only it does acknowledge, so it keeps a bus alive; unlike normal it cannot originate traffic or disturb it.

How it is built

The node drives dominant only in the ACK slot. Every other dominant drive is suppressed.
Transmission requests are held pending rather than executed, so software queues are not lost.
Error flags are suppressed, so a node with a wrong configuration cannot destroy traffic it does not understand.
The node still runs its receive error counter, so it keeps a view of bus health.
It is typically entered automatically by hardware on a protocol exception, and left under software control.

Design procedure

Use it as the safe landing state after a protocol exception, where the node's own understanding of the bus may be wrong.
Use it during a bit-rate or configuration change where the node must keep acknowledging but must not transmit.
Poll the mode status, since hardware may have entered it without software asking.
Diagnose the cause before leaving: an unexpected entry usually means the node saw a frame format it was not configured for.
Leave the mode explicitly through initialisation once the configuration is corrected.

Key terms

Restricted operation: Receives and acknowledges; never transmits frames, error flags, or overload frames.
Protocol exception: A reserved-bit combination indicating a frame format this node does not implement, such as CAN XL arriving at an FD-only node.
Overload frame: A frame a receiver sends to request extra delay before the next frame. Suppressed in this mode.
Pending transmission: A queued frame held rather than discarded while the mode is active.
Graceful degradation: The design intent: a confused node stops contributing rather than corrupting.

Worked example

Why the mode exists, in one scenario. An FD-only node meets a CAN XL frame
it cannot decode. Its options are:

  signal an error    destroys a frame that is perfectly valid for the
                     XL-capable nodes, and repeats forever
  go bus-off         the node drops off the network entirely
  restricted op      stops transmitting, keeps acknowledging what it
                     does understand, lets software decide

The third is the only one that neither corrupts the bus nor loses the node.

Common pitfalls

Error-active, error-passive, and bus-off

These are not configured modes but states the protocol engine enters on its own, driven by two counters. Every node begins error-active, able to signal errors with six dominant bits. Sustained errors push it to error-passive, where its error flags are recessive and cannot disturb others. Continued failure takes it bus-off, disconnected from the bus entirely. The mechanism exists so one faulty node cannot hold a whole network down.

How it is built

TEC increases by 8 on a transmit error and decreases by 1 on a successful transmission; REC increases by 1 on a receive error and decreases by 1 on success.
Error-active: both counters below 128. The node signals errors with an active error flag of six dominant bits, which every other node sees.
Error-passive: either counter at 128 or above. Error flags become six recessive bits, which cannot destroy another node's frame.
An error-passive transmitter must additionally wait eight extra recessive bits, the suspend transmission field, before starting again, giving healthier nodes priority.
Bus-off: TEC reaches 256. The node stops all bus activity. Recovery needs 128 occurrences of eleven consecutive recessive bits, and on most controllers an explicit software request.

Design procedure

Read TEC and REC rather than only the state flags; a counter climbing steadily is a fault developing before any state changes.
Treat the first transition to error-passive as a real fault report, not a transient to be cleared.
On bus-off, diagnose before recovering: automatic recovery loops hide a permanent wiring fault behind an endlessly restarting node.
If recovery is automatic, rate-limit it and count occurrences so a persistent fault is visible to the application.
Log the counters at the moment of transition, since they are the only evidence of what happened once recovery resets them.

Key terms

TEC: Transmit error counter. +8 per transmit error, -1 per success. Reaches 256 at bus-off.
REC: Receive error counter. +1 per receive error, -1 per success. Cannot by itself cause bus-off.
Active error flag: Six dominant bits. Deliberately violates bit stuffing so every node sees the error.
Passive error flag: Six recessive bits. Signals locally without destroying the frame for anyone else.
Bus-off recovery: 128 occurrences of 11 recessive bits. At 500 kbit/s on an idle bus roughly 3 ms; on a busy bus far longer.

Worked example

The asymmetry is the whole design:

  transmit error  TEC += 8
  transmit ok     TEC -= 1

A node failing one transmission in eight is net-zero and survives. A node
failing more often climbs to 256 and removes itself.

  a lone node, automatic retransmission on:
     attempt  1   no ACK   TEC = 8
     attempt  2   no ACK   TEC = 16
     ...
     attempt 32   no ACK   TEC = 256  -> BUS-OFF

At 500 kbit/s with a short frame this takes under a millisecond, which is why
the node appears to fail instantly on the bench.

Common pitfalls

Sleep, standby, and wake-up

CAN nodes in vehicles spend most of their life powered but asleep. Low-power behaviour is split between the controller, which can stop its clock, and the transceiver, which has its own standby and sleep states with a wake-up receiver. Getting the two out of step is a classic field failure: a node that never wakes, or one that wakes and immediately corrupts the first frame on the bus.

How it is built

Controller sleep stops the protocol engine's clock, dropping power to near zero. It cannot receive while asleep.
Transceiver standby disables the transmitter and switches the receiver to a slower, lower-power wake-up detector.
A wake-up pattern - a defined dominant-recessive-dominant sequence rather than any single edge - avoids waking a whole network on noise.
On wake the transceiver signals the controller, which must restart its clock and resynchronise to eleven recessive bits before transmitting.
Partial networking lets a transceiver stay asleep until a specific identifier appears, so a node ignores traffic that does not concern it.

Design procedure

Put the controller into initialisation before requesting sleep, so no transmission is left half-complete.
Request transceiver standby only after the controller has stopped, or the transceiver may sleep while a frame is being driven.
On wake, restore bit timing and filters, since some controllers lose them, then wait for bus idle.
Do not transmit on the wake-up frame itself; the node was not synchronised while it arrived and will misread it.
Verify the whole cycle at temperature: wake-up detector thresholds and oscillator start-up time both move with temperature.

Key terms

Standby: Transceiver low-power state with the transmitter off and a wake-up receiver active.
Sleep: A deeper state; on many transceivers the wake-up source is restricted and current is lower still.
Wake-up pattern: A defined dominant-recessive-dominant sequence, so noise does not wake a vehicle network.
Partial networking: Selective wake on a configured identifier, letting a node sleep through traffic it does not need.
Local wake: A wake triggered by the node's own hardware, such as a switch, rather than by bus activity.

Worked example

Sequencing matters in both directions, and getting it backwards is the bug:

  going to sleep                  waking up
   1 finish pending TX             1 transceiver detects wake pattern
   2 controller -> init            2 transceiver -> normal, asserts wake
   3 controller -> sleep           3 controller clock restarts
   4 transceiver -> standby        4 restore timing and filters
                                   5 wait for 11 recessive bits
                                   6 only now may this node transmit

Step 4 before step 3 lets the transceiver sleep mid-frame. Skipping step 5
puts a desynchronised transmitter onto a live bus.

Common pitfalls

One-shot transmission and automatic retransmission

By default a CAN controller retransmits a frame that lost arbitration or hit an error, without software involvement, until it succeeds. One-shot mode - automatic retransmission disabled - makes each transmission a single attempt: if it fails the frame is abandoned and software is told. The choice matters for anything time-sensitive, because the default silently replaces a fresh value with a stale one.

How it is built

With automatic retransmission on, a frame stays in its transmit mailbox until it is acknowledged, however long that takes.
With one-shot, the mailbox is released after the first attempt regardless of outcome, and a status flag reports what happened.
One-shot is required for time-triggered CAN, where a frame belongs to a specific time slot and is worthless outside it.
It also bounds the damage from a node alone on the bus: TEC rises by 8 once rather than climbing to bus-off in milliseconds.
Some controllers set the policy per mailbox rather than globally, which lets periodic and event frames differ.

Design procedure

Choose one-shot when a newer value will exist before a retry could succeed: control setpoints, sensor samples, anything periodic.
Choose automatic retransmission for commands that must arrive, such as configuration writes or diagnostic requests.
In one-shot mode, check the completion status of every transmission; a silently dropped frame is the expected failure, not an exception.
Do not re-queue a dropped periodic frame from software. The next period's fresh value is more useful than the stale one.
During bring-up, one-shot keeps a lone node off bus-off long enough to actually observe what is happening.

Key terms

Automatic retransmission: The default. Hardware retries until acknowledged.
One-shot: Single attempt; the frame is discarded on failure and software is notified.
Arbitration loss: A higher-priority frame won the identifier field. With retransmission on, this is invisible to software.
Time-triggered CAN: ISO 11898-4. Frames belong to time slots, so retransmission into a later slot is wrong by definition.
Transmit mailbox: The hardware buffer holding a frame awaiting transmission.

Worked example

A 10 ms control loop is exactly where the default does harm:

  automatic retransmission
    t = 0 ms   queue setpoint A, bus busy, retrying
    t = 10 ms  queue setpoint B, mailbox still holds A
    t = 14 ms  A finally sent          <- a 14 ms stale value arrives

  one-shot
    t = 0 ms   queue A, attempt fails, A discarded, flag set
    t = 10 ms  queue B, succeeds       <- receiver gets the current value

The one-shot bus dropped a frame. The retransmitting bus delivered a wrong
number, which is worse, and did it without telling anyone.

Common pitfalls

Why CAN FD exists: the arbitration ceiling

Classical CAN cannot go faster, and the reason is not the transceiver. Arbitration is non-destructive: two nodes may transmit at once, and the one sending a dominant bit must overwrite the other within a single bit time. That requires a signal to travel to the far end of the bus and back while one bit is still on the wire, which ties the maximum bit rate to the physical length of the network. CAN FD's insight is that this constraint applies only while more than one node might be transmitting - during arbitration. Once arbitration is settled there is exactly one transmitter, propagation no longer needs to close a loop, and the bit rate can rise.

How it is built

During arbitration a bit must propagate to the furthest node and back within one bit time, so bit time is bounded below by round-trip delay.
At roughly 5 ns/m in twisted pair, a 40 m bus needs about 400 ns of round-trip allowance, which is why 1 Mbit/s at 40 m is a common practical ceiling.
After the arbitration field only the winner transmits. No other node needs to overwrite anything, so the round-trip constraint disappears.
CAN FD therefore uses two bit rates in one frame: the nominal rate through arbitration, and a higher data rate through the payload and CRC.
The payload also grows from 8 to 64 bytes, which matters more than the bit rate for overhead: a classical 8-byte frame is roughly half header.

Design procedure

Choose the nominal bit rate from bus length and topology exactly as for classical CAN; FD does not relax this.
Choose the data bit rate from the transceiver's loop delay and the sample point margin, not from bus length.
Verify that every node on the bus is FD-capable, or at least FD-tolerant, before enabling FD frames.
Size the payload to the message, remembering that DLC above 8 is a coarse table rather than a byte count.
Measure the resulting bus load; FD reduces the time a message occupies the bus, which is usually the real goal.

Key terms

Nominal bit rate: The arbitration-phase rate, bounded by bus length. Typically 500 kbit/s or 1 Mbit/s.
Data bit rate: The rate used from BRS to the CRC delimiter, bounded by transceiver loop delay. Commonly 2 or 5 Mbit/s.
Non-destructive arbitration: The property that a dominant bit overwrites a recessive one, letting the highest-priority frame survive a collision undamaged.
Propagation segment: The part of the bit reserved for round-trip delay. It is what makes long buses slow.
Bus load: The fraction of time the bus is busy. The practical reason to adopt FD.

Worked example

Where the time actually goes, for 64 bytes of application data:

  classical CAN, 500 kbit/s
    8 frames x roughly 130 bits = 1040 bits = about 2.1 ms
    payload is 512 of those bits: about 49% efficient

  CAN FD, 500 kbit/s nominal + 2 Mbit/s data
    1 frame: about 30 bits at 500k, about 550 bits at 2M
    = 60 us + 275 us = about 0.34 ms
    roughly 6x less bus time for the same data

The gain comes from both changes together. A bigger payload alone would still
pay classical bit times; a faster rate alone would still pay eight headers.

Common pitfalls

The FD frame: BRS, ESI, FDF, and what changed on the wire

An FD frame is recognisably a CAN frame with three new control bits and two restrictions. FDF, previously a reserved dominant bit, is recessive to mark the frame as FD. BRS decides whether the data phase switches to the faster bit rate. ESI carries the transmitter's own error state so receivers can see it directly. The restrictions are that FD frames have no RTR - remote frames do not exist in FD - and that the identifier field is otherwise unchanged, so classical and FD frames arbitrate against each other normally.

How it is built

FDF, formerly r0 in classical CAN, is recessive in an FD frame. A classical controller sees a form error here, which is why mixing requires care.
BRS, bit rate switch: recessive means the data phase runs at the data bit rate; dominant means the whole frame stays at the nominal rate.
The bit rate changes at the BRS bit's sample point and changes back at the CRC delimiter, so the switch points are defined by the protocol, not by software.
ESI, error state indicator: dominant while the transmitter is error-active, recessive while it is error-passive.
RTR does not exist in FD. The bit position is reallocated to RRS and is always dominant, so remote frames are a classical-only feature.

Design procedure

Set FDF to send an FD frame at all; without it the controller emits a classical frame regardless of payload size.
Set BRS separately. FD without BRS is legitimate and useful: 64-byte payloads at the nominal rate, on a bus whose transceivers cannot go faster.
Do not attempt to send a remote frame in FD; request-response must be built from two data frames.
Read ESI on reception to learn that a peer is struggling before it disappears into bus-off.
Confirm that receivers are configured to accept FD frames; an FD-capable controller can still be configured classical-only.

Key terms

FDF: Formerly r0. Recessive marks an FD frame. Sometimes called EDL, extended data length.
BRS: Bit rate switch. Recessive switches the data phase to the fast rate; dominant keeps the whole frame nominal.
ESI: Error state indicator. Recessive means the transmitter is error-passive - a health signal that classical CAN never had.
RRS: Remote request substitution. The always-dominant bit occupying the old RTR position in FD.
Form error: A fixed-format bit found at the wrong level. What a classical controller reports when it meets a recessive FDF.

Worked example

Two frames, same identifier, drawn to the same scale:

  classical, 8 bytes @ 500k
    SOF | ID(11) | RTR | IDE r0 | DLC(4) | data(64) | CRC(15) | ACK | EOF
    <----------------------- all at 500 kbit/s ----------------------->

  FD, 64 bytes @ 500k nominal / 2M data
    SOF | ID(11) | RRS | IDE FDF | res BRS ESI | DLC(4) | data(512) | CRC(21) | CRC del | ACK | EOF
    <--- 500 kbit/s ------------>|<-------- 2 Mbit/s ---------------->|<--- 500 kbit/s --->
                                 ^                                    ^
                       switch at BRS sample point        switch back at CRC delimiter

The two switch points are protocol-defined. Nothing in software chooses them.

Common pitfalls

The FD DLC table: why 9 to 15 are not byte counts

Classical CAN uses a 4-bit DLC where values 0 to 8 mean 0 to 8 bytes and 9 to 15 are all treated as 8. CAN FD reuses those seven wasted codes to reach 64 bytes, but four bits cannot express 65 lengths, so the codes above 8 map to a fixed table with gaps: 12, 16, 20, 24, 32, 48, 64. Payload lengths between the table entries do not exist on the wire. A 40-byte message is transmitted as 48 bytes with 8 bytes of padding, and the receiver has no protocol-level way to know the message was really 40.

How it is built

DLC 0 to 8 mean exactly 0 to 8 bytes, identical to classical CAN.
DLC 9 to 15 mean 12, 16, 20, 24, 32, 48 and 64 bytes respectively.
The steps are 4 bytes up to 24, then 8, then 16, then 16 - the granularity gets worse as the payload grows.
A transmitter must pad up to the next available size; the protocol carries no length field finer than the DLC.
Padding bytes are ordinary data bytes and are covered by the CRC, so they cost bus time and must be given a defined value.

Design procedure

Design message layouts to land on a table size, so no padding is transmitted at all.
Where padding is unavoidable, fill with a defined constant rather than uninitialised memory, which otherwise leaks stack contents onto the bus.
If the true length matters to the receiver, carry it in the payload; the DLC cannot express it.
Remember the cost: a 33-byte message occupies 48 bytes of bus time, a 45% overhead invisible in the application code.
When choosing between two layouts, prefer the one that fits a table size even if it is slightly less tidy.

Key terms

DLC: Data length code, 4 bits. In FD it indexes a table rather than counting bytes directly.
Padding: Bytes added to reach the next table size. Ordinary data as far as the protocol is concerned.
Table granularity: 4 bytes up to 24, then 8, then 16. Larger payloads waste more.
Length signalling: Any application-level field carrying the real length, needed because the DLC cannot.
CAN FD frame overhead: Roughly 30 nominal-rate bits plus the fast-rate payload and CRC.

Worked example

The full table, and the cost of missing it:

  DLC   0 1 2 3 4 5 6 7 8   9  10  11  12  13  14  15
  bytes 0 1 2 3 4 5 6 7 8  12  16  20  24  32  48  64

  a 40-byte message
    nearest size at or above 40 is 48  (DLC 14)
    8 bytes of padding, 17% of the payload wasted

  a 33-byte message
    nearest size is 48 as well
    15 bytes of padding, 45% wasted

Dropping one byte from that 33-byte layout fits DLC 13 at 32 bytes and removes
the padding entirely - a third off the bus time for one field.

Common pitfalls

Bit timing in two phases, and the transceiver loop delay

An FD controller has two complete bit timing configurations: one for arbitration and one for the data phase. The arbitration configuration is chosen exactly as for classical CAN, from bus length. The data configuration is bounded by something entirely different - the round-trip delay through the transmitting node's own transceiver. Above roughly 1 Mbit/s that delay becomes a significant fraction of a bit time, and a transmitter checking its own bit against the wire will read the previous bit instead. This is what the secondary sample point exists to fix.

How it is built

Each phase has its own prescaler, propagation and phase segments, and synchronisation jump width; they are independent register sets.
The data-phase bit time no longer needs a propagation segment sized for the bus, because only one node is transmitting.
Transceiver loop delay is the time from the controller's transmit pin, through the transceiver, onto the bus, back through the receiver, to the receive pin - typically 100 to 250 ns.
At 5 Mbit/s a bit is 200 ns, so the loop delay can exceed a whole bit time; the transmitter's own bit monitoring would compare against the wrong bit.
Transmitter delay compensation measures the actual delay at the FDF-to-BRS edge of every frame and places a secondary sample point that far after the transmit point.

Design procedure

Configure the arbitration timing first, from bus length and the slowest node's oscillator tolerance.
Configure the data timing from the transceiver's datasheet loop delay, not by scaling the arbitration settings.
Enable transmitter delay compensation for any data rate above about 1 Mbit/s; below that the delay is a small fraction of a bit.
Set the secondary sample point offset to approximately the measured loop delay plus the data-phase propagation segment.
Verify with a scope at the transceiver pins, and at temperature - loop delay drifts, and the margin is small.

Key terms

TDC: Transmitter delay compensation. Measures loop delay per frame and positions the secondary sample point.
SSP: Secondary sample point. Where the transmitter checks its own transmitted bit, separate from where receivers sample.
Loop delay: Transmit pin to receive pin round trip through the transceiver, typically 100-250 ns.
SJW: Synchronisation jump width. How much the bit time may stretch or shrink to resynchronise.
Oscillator tolerance: Combined with SJW and the sample point, it sets how far two nodes' clocks may differ before frames fail.

Worked example

Why TDC is not optional at high data rates:

  data rate 5 Mbit/s   ->  bit time 200 ns
  transceiver loop delay   200 ns

  without TDC
    the transmitter samples its own bit at, say, 70% of the bit,
    at t = 140 ns; the level arriving back is from the bit that
    started 200 ns ago -> it is checking the PREVIOUS bit
    -> spurious bit errors on every frame

  with TDC
    delay is measured at the FDF-to-BRS edge each frame
    SSP is placed at 200 ns + propagation offset after transmit
    -> the transmitter checks the bit it actually sent

The delay is measured every frame rather than configured once because it moves
with temperature and supply voltage.

Common pitfalls

Stuffing and the two CRCs: ISO versus non-ISO FD

CAN FD changed both the CRC and the stuffing rules, and got it wrong the first time. The original 2012 specification had a flaw: under specific stuff-bit conditions a corrupted frame could still produce a valid CRC, weakening the guarantee CAN exists to provide. ISO 11898-1:2015 fixed it by adding a stuff bit count field, protected by its own parity, into the CRC calculation. The two variants are not interoperable, and controllers built before the fix are still in the field, so the distinction is a real deployment concern rather than history.

How it is built

The arbitration phase uses classical dynamic bit stuffing: after five identical bits, insert one of opposite polarity.
The data phase keeps dynamic stuffing for the payload but adds fixed stuff bits in the CRC field - one every four bits, at known positions.
Fixed stuffing makes the CRC field's length deterministic, which matters because the receiver must know exactly where the CRC ends.
The CRC polynomial grew with the payload: 17 bits for payloads up to 16 bytes, 21 bits for larger ones, replacing the classical 15-bit CRC.
ISO FD adds a 3-bit stuff bit count plus a parity bit before the CRC, and includes them in the CRC calculation. Non-ISO FD omits them entirely.

Design procedure

Determine which variant every controller on the bus implements before designing anything; this is a datasheet question, not a configuration one.
Configure all nodes identically. A mixed bus does not degrade gracefully - it produces constant CRC errors.
Prefer ISO FD for anything new; non-ISO exists only to interoperate with early silicon.
If a controller supports both, set the variant explicitly rather than relying on a reset default.
When debugging unexplained CRC errors on an otherwise healthy FD bus, check the variant before the wiring.

Key terms

Dynamic stuffing: A bit of opposite polarity after five identical bits, so receivers always have edges to synchronise on.
Fixed stuffing: Stuff bits at known positions in the FD CRC field, one every four bits, making the field length deterministic.
Stuff bit count: A 3-bit field plus parity, counting dynamic stuff bits. The ISO fix, included in the CRC.
CRC-17 / CRC-21: FD CRC polynomials, chosen by payload size: 17 bits up to 16 bytes, 21 bits above.
Non-ISO FD: The original 2012 variant, without the stuff bit count. Incompatible with ISO FD on the same bus.

Worked example

What the two variants put on the wire, and why they cannot share a bus:

  non-ISO FD    ... | data | CRC(17 or 21) | CRC del | ACK | ...
  ISO FD        ... | data | SBC(3) + parity | CRC(17 or 21) | CRC del | ACK | ...

An ISO receiver meeting a non-ISO frame reads the first CRC bits as the stuff
bit count, so every subsequent bit is misaligned and the CRC fails. A non-ISO
receiver meeting an ISO frame reads the count field as CRC bits, with the same
result. Neither reports anything more helpful than a CRC error, which is why
this is usually diagnosed last and should be checked first.

Common pitfalls

Mixing classical and FD nodes on one bus

A classical CAN controller does not ignore an FD frame; it rejects it. The FDF bit that marks a frame as FD sits where classical CAN expects a dominant reserved bit, so a classical node reads a form error and transmits an error flag - six dominant bits that destroy the frame for everyone. One classical node on an FD bus is enough to prevent any FD frame from ever completing. There are only three real strategies, and choosing between them is a network architecture decision.

How it is built

A classical controller sees recessive FDF as a form error and responds with an active error flag, corrupting the frame mid-flight.
The transmitter retries, hits the same error, and TEC climbs by 8 each time until it goes bus-off.
FD-tolerant classical controllers exist: they recognise FD frames well enough to stay silent through them, without decoding the contents.
A gateway can bridge an FD segment and a classical segment, translating and re-fragmenting messages between them.
The last option is a flag day: replace every node at once, which is the only approach that gets the full benefit.

Design procedure

Inventory every node on the bus, including diagnostic tools and end-of-line testers, which are frequently the forgotten classical devices.
Confirm FD tolerance from the datasheet; assuming it from the part being recent is not sufficient.
If any node is classical and not FD-tolerant, either replace it, move it behind a gateway, or do not use FD on that segment.
During migration, FD frames without BRS are often the safer first step, since they do not additionally stress the physical layer.
Test with the diagnostic tool attached, since that is the configuration the bus will actually be serviced in.

Key terms

FD-tolerant: A classical controller that stays silent during FD frames instead of erroring, without decoding them.
Form error: A fixed-format bit at the wrong level. What a classical node reports on seeing a recessive FDF.
Gateway: A dual-controller node bridging an FD segment to a classical one, with translation and fragmentation.
Flag day: Replacing every node at once. The only way to get the full FD benefit on an existing network.
Segment: One electrically continuous bus. FD and classical can coexist across segments but not on one.

Worked example

What one classical node does to an FD bus:

  FD node transmits    SOF ID ... FDF(recessive) ...
  classical node       reads recessive where r0 must be dominant
                       -> FORM ERROR
                       -> transmits 6 dominant bits
  every node           frame destroyed, discarded
  FD transmitter       TEC += 8, retransmits
  ... 32 attempts ...  TEC = 256 -> BUS-OFF

The FD node is removed from the bus in under a millisecond, and the fault
looks like a broken FD node rather than an incompatible classical one.

Common pitfalls

The physical layer at 2 to 8 Mbit/s

The data phase runs the same wire far faster than it was ever specified for, and the physical layer stops forgiving. At 500 kbit/s a bit is 2 microseconds and a stub or a reflection is a rounding error; at 5 Mbit/s a bit is 200 nanoseconds and the same stub is a substantial fraction of it. Ringing, stub length, termination accuracy, and transceiver symmetry all become real constraints rather than good practice, and the classical linear-bus-with-two-terminators topology reaches its limit.

How it is built

Reflections from an unterminated or badly terminated end return and are sampled as data if they arrive near the sample point.
Stub length matters directly: a stub acts as an unterminated transmission line, and its round trip must be small compared with a bit time.
Termination must be 120 ohms at both ends and nowhere else; an extra terminator halves the impedance and the signal amplitude with it.
Split termination - two 60 ohm resistors with a capacitor to ground at the midpoint - improves common-mode behaviour and emissions at high rates.
Transceiver symmetry, the matching of dominant-to-recessive and recessive-to-dominant transition times, is specified explicitly for FD-capable parts.

Design procedure

Keep the topology a linear bus. Star and hybrid topologies that work at 500 kbit/s frequently fail in an FD data phase.
Keep stubs to a few centimetres; at 5 Mbit/s a 30 cm stub is a significant part of a bit time.
Measure termination with the bus unpowered: expect about 60 ohms across CANH and CANL, which is the two terminators in parallel.
Choose transceivers explicitly rated for the intended data rate; a classical part may work at 2 Mbit/s and fail at 5.
Probe at the receiving node furthest from the transmitter, not at the transmitter, since that is where the eye is worst.

Key terms

Split termination: Two 60 ohm resistors in series across the pair with a capacitor from the midpoint to ground; improves common-mode rejection and emissions.
Stub: The branch from the main bus to a node. Effectively an unterminated line, so its length is bounded by bit time.
Ringing: Reflection-induced oscillation after an edge. Harmless if it settles before the sample point, fatal if it does not.
Symmetry: Matching of the two transition directions in a transceiver. Specified for FD parts because asymmetry eats the eye at high rates.
Eye diagram: Overlaid bit periods showing the margin actually available at the sample point.

Worked example

Why the same harness behaves differently in the two phases:

  500 kbit/s   bit = 2000 ns
    a 30 cm stub, round trip about 3 ns  ->  0.15% of a bit, invisible

  5 Mbit/s     bit = 200 ns
    same 30 cm stub, same 3 ns           ->  1.5% of a bit
    plus ringing that needs several round trips to settle,
    now occupying a real share of the time before the sample point

The wire did not change. The time available to it did, by a factor of ten, and
that is the whole difficulty of the FD physical layer.

Common pitfalls

Choosing FD parameters, and where CAN XL goes next

Adopting FD means choosing two bit rates, a payload strategy, and a variant, and each choice trades bus time against margin. There is no single right answer, but there is a defensible method: fix the nominal rate from topology, fix the data rate from transceiver and harness margin, then size messages to the DLC table. Beyond FD, CAN XL raises the payload to 2048 bytes and adds a data-phase rate up to 20 Mbit/s with a different transceiver mode, which is worth understanding when deciding whether FD is the right destination or a waypoint.

How it is built

Nominal rate is a topology decision: bus length, node count, and the worst oscillator tolerance on the bus.
Data rate is a margin decision: transceiver loop delay, stub lengths, termination quality, and temperature range.
A conservative and common pair is 500 kbit/s nominal with 2 Mbit/s data, which most FD transceivers and harnesses handle without special care.
5 Mbit/s data is achievable but demands short stubs, split termination, rated transceivers, and measured margin.
CAN XL extends to 2048-byte payloads and up to about 20 Mbit/s using a dedicated transceiver mode, and reintroduces a protocol-level length field, removing the DLC padding problem.

Design procedure

Start from the message set: total bytes per period, and the deadline for the tightest message.
Pick the nominal rate that the topology supports, then check whether arbitration alone already meets the deadline.
Pick the lowest data rate that meets the bus-load target, since every step up costs physical-layer margin.
Lay out messages on DLC table boundaries before committing, because padding is bus time bought for nothing.
Measure real bus load on hardware rather than trusting the calculation, and leave headroom for diagnostics and future messages.

Key terms

Bus load target: Commonly 30-50% for event-driven traffic, so latency stays bounded under burst conditions.
Worst-case latency: For the lowest-priority message: its own transmission time plus every higher-priority frame that can pre-empt it.
CAN XL: The next generation: 2048-byte payloads, data rates to roughly 20 Mbit/s, and an explicit length field.
PWM mode: The CAN XL data-phase signalling scheme, requiring an XL-capable transceiver.
Headroom: Bus capacity deliberately left unused, for diagnostics, future messages, and burst tolerance.

Worked example

A worked parameter choice for a 12-node, 15 m powertrain bus:

  topology     15 m, 12 nodes, short stubs
  nominal      500 kbit/s   (1 Mbit/s is possible at 15 m, but 500k
                             costs nothing here and buys margin)
  data         2 Mbit/s     (5 Mbit/s would need stub and termination
                             work for a gain the load does not need)
  variant      ISO FD       (nothing on this bus predates 2015)
  payloads     sized to 8, 12, 16, 32 - no padding anywhere
  measured     31% bus load at 2 Mbit/s, against 74% classical

The deciding number is the last one. Classical at 74% has unbounded latency
under burst; FD at 31% does not, and that is the actual reason to migrate.

Common pitfalls

The mental model

CAN has no addresses and no master. Every node transmits onto a shared differential pair whenever the bus is idle, and each message begins with an identifier that describes what the message is rather than who it is for. When two nodes start together, the identifier itself resolves the collision: a dominant bit physically overrides a recessive one, so the node transmitting the numerically lower identifier wins and the loser stops without any data being corrupted. That non-destructive arbitration is the single idea the whole protocol is built on.

It is the network inside every vehicle and most industrial machinery, and the properties that made it win are the ones that matter under fault conditions: no single node's failure stops the bus, priority is deterministic so a brake message always beats a comfort message, and every node checks every frame so errors are detected globally rather than by the recipient alone. The consequence is that CAN faults are usually electrical or node-level rather than logical, and the error counters are the diagnostic that tells you which.

Core rules

Identifiers name messages, not nodes

A frame says what it contains, and any node that cares receives it. Adding a listener requires no change anywhere else, which is why vehicle architectures scale this way.

Arbitration is non-destructive and priority is the identifier

Dominant zero overrides recessive one. A node that sees a dominant bit where it sent a recessive one has lost and withdraws silently, having corrupted nothing. The winner's frame continues undisturbed.

The lowest identifier is the highest priority

This makes priority a design-time allocation. Assigning identifiers is an architectural decision about worst-case latency, not a naming convenience.

Bit timing is divided into segments and the sample point matters

Each bit is split into time quanta with a sample point typically at 75 to 87.5%. Nodes with mismatched sample points can communicate at short range and fail as the bus lengthens.

The acknowledgement is collective

Any node that receives a frame correctly drives the ACK slot dominant. A transmitter therefore cannot tell who acknowledged - only that at least one node did. A single node alone on a bus never gets an ACK and retransmits forever.

Error counters isolate a faulty node

Each node counts its own transmit and receive errors. Passing 127 makes it error-passive; passing 255 makes it bus-off and it stops transmitting entirely. This is how a broken node removes itself instead of destroying the bus.

Bit stuffing keeps receivers synchronised

After five identical consecutive bits a complementary bit is inserted, guaranteeing edges for resynchronisation. It also means the frame length varies with the data.

Bus length and bit rate trade against each other

Arbitration requires a bit to propagate to the far end and back within one bit time, so 1 Mbit/s is limited to roughly 40 metres. The relationship is not linear and it is not negotiable.

Workflow

Measure termination first: 60 ohms across a powered-down bus means two 120 ohm terminators, which is correct. Anything else is the problem.
Read the error counters on every node. A node that is bus-off or error-passive names itself as the fault without further searching.
Check that every node's bit timing produces the same nominal rate and a compatible sample point, not just the same headline bit rate.
Confirm at least two nodes are active. A single node cannot get an acknowledgement and will retransmit endlessly, which on a scope looks like a node that will not stop talking.
Scope CANH and CANL together and look at the differential. A stuck-dominant node holds the bus and prevents everyone; it is found by disconnecting nodes one at a time.
Verify bus length against bit rate before assuming a software fault. A bus that works at 250 kbit/s and fails at 1 Mbit/s is telling you about propagation, not code.

Worked example

Arbitration, bit by bit

three nodes start transmitting simultaneously.
dominant = 0 and physically overrides recessive = 1.

              id bit:  10  9  8  7  6  5  4  3 ...
  node A (id 0x0F0):    0  0  0  1  1  1  1  0
  node B (id 0x123):    0  0  1  <- sees 0, LOSES here
  node C (id 0x0F5):    0  0  0  1  1  1  1  0
                                             |
  bus (wired-AND):      0  0  0  1  1  1  1  0

              id bit:   2  1  0
  node A:               0  0  0
  node C:               1  <- sees 0, LOSES here
  bus:                  0  0  0

  -> node A wins and its frame continues uninterrupted.
  -> B and C become receivers and retry when idle.
  -> nothing was corrupted, no bandwidth was wasted,
     and the outcome was decided purely by identifier.

compare Ethernet: a collision destroys both frames and
both nodes back off randomly. CAN wastes nothing, which
is why it can guarantee worst-case latency for the
highest-priority message.

The lack of any wasted bandwidth is what makes CAN's timing analysable. Because the highest-priority message never loses arbitration, its worst-case latency is bounded by the longest frame already in progress - a number you can compute at design time, which is what a safety argument requires.

Vocabulary

Dominant / recessive: Logical zero overrides logical one on the wired-AND bus. The basis of arbitration.
Arbitration: Collision resolution by identifier, non-destructive: the winner's frame is unaffected.
Identifier: 11 or 29 bits naming the message content and setting its priority. Lower wins.
ACK slot: A bit any correct receiver drives dominant. Collective, so the sender learns only that someone heard.
Error-passive / bus-off: States a node enters at 128 and 256 errors, progressively removing itself from the bus.
Bit stuffing: A complementary bit inserted after five identical bits to guarantee edges.
Sample point: Where in the bit the level is read, typically 75-87.5%. Must be compatible across nodes.
Time quantum: The bit timing's atomic unit. Segments are counted in these.

More in Connectivity

SPISPI bus modes (CPOL/CPHA), clock polarity, phase, and multi-slave chip-select. Interactive lab for MOSI/MISO timing.
TCPTCP from first principles to advanced: full header field explorer, three-way handshake with real seq/ack numbers and SYN-loss retransmission, animated sliding-window data transfer with scripted packet loss, congestion control (slow start, congestion avoidance, cwnd halving), and window-vs-BDP throughput. Interactive simulator plus theory.
UARTUART frame structure, baud rate calculation, start/stop bits, parity, and flow control. Interactive simulator for TX/RX timing analysis.
I2CI2C protocol: start/stop conditions, addressing, ACK/NACK, clock stretching, and multi-master arbitration. Interactive simulator.
I2S AudioI2S audio: word select, bit clock and MCLK arithmetic, Philips versus left-justified alignment, and the one-bit shift that ruins audio while the signals look perfect.
1-Wire1-Wire: bit values encoded as pulse duration, the interrupt jitter budget, reset and presence, ROM search as a binary tree walk, CRC-8, and parasitic power.
Framing & COBSMessage framing on a byte stream: length prefixes, byte stuffing, SLIP and COBS, and why resynchronisation after a lost byte decides which one you should use.
LIN BusLIN bus: break and sync-byte calibration for crystal-less slaves, protected identifier parity, classic versus enhanced checksums, and offline schedule tables.
LoRaWANLoRaWAN: spreading factor against airtime, duty cycle limits, Class A downlink windows, OTAA versus ABP, frame counters and adaptive data rate.
MQTTMQTT publish/subscribe: topic hierarchy design, QoS 0/1/2 delivery guarantees, retained messages, last will, keep-alive and persistent sessions.
HTTP / HTTPSHTTP request and response framing, status code categories, Content-Length versus chunked encoding, keep-alive, and safe retry policy per method.
TLS SecurityTLS on embedded targets: what certificate validation actually checks, why the clock is a security dependency, trust stores, forward secrecy and rotation.