CAN Bus: Frame Format, Arbitration, Bit Stuffing

CAN Bus Overview and Relevance

Why CAN dominates automotive and industrial systems

Controller Area Network (CAN) was introduced by Bosch in 1986 to solve a wiring problem: luxury vehicles were accumulating so many point-to-point harnesses between ECUs that weight, cost, and failure points were spiraling. CAN replaced that mesh with a single twisted-pair bus that every node shares. Three decades later it's still the backbone of in-vehicle networks (powertrain, body control, chassis) and a staple in industrial automation (motor drives, PLCs, sensor networks) because it offers something rare in low-cost serial buses: deterministic, priority-based arbitration with hardware-guaranteed error detection, running reliably over twisted pair at distances up to 40 m at 1 Mbit/s or several hundred meters at lower rates (consult ISO 11898-2 for exact distance/bitrate tables for your transceiver).

Multi-master, collision-free communication

CAN has no bus master. Any node can attempt to transmit when the bus is idle, and the protocol itself resolves contention without retransmission delay or data loss — a property that distinguishes it sharply from Ethernet-style CSMA/CD, where collisions destroy both frames and force random backoff. Understanding exactly how that resolution happens at the bit level — not just "CAN handles priority automatically" — is what separates engineers who can read a bus trace during a field failure from those who can't.

CAN Frame Structure

Standard (11-bit) vs. Extended (29-bit) identifiers

CAN 2.0A defines an 11-bit identifier (2048 possible values, though not all are usable due to reserved patterns); CAN 2.0B extends this to 29 bits via an 18-bit extension appended after an IDE (Identifier Extension) bit. The two formats coexist on the same physical bus — a receiver's hardware filter has to be configured to accept both if the network mixes them. Extended frames exist because automotive and industrial systems (J1939 in particular) ran out of ID space and needed room to encode source address, PGN, and priority bits within the identifier itself.

Frame components: SOF, arbitration field, control field, data field, CRC, ACK, EOF

A standard data frame, bit by bit:

SOF(1) | ID[10:0](11) | RTR(1) | IDE(1) | r0(1) | DLC(4) | DATA(0-64) | CRC(15) | CRC-DELIM(1) | ACK(1) | ACK-DELIM(1) | EOF(7)

• SOF — a single dominant bit marking the start of frame and triggering hard synchronization on all nodes.
• Arbitration field — the identifier plus RTR bit; this is where priority contention is resolved.
• Control field — IDE, reserved bit, and the 4-bit DLC.
• Data field — 0 to 8 bytes (classical CAN; CAN FD extends this up to 64 bytes).
• CRC field — 15-bit checksum plus a recessive delimiter.
• ACK field — a slot any listening node pulls dominant to acknowledge receipt.
• EOF — 7 recessive bits marking frame end.

Data payload and DLC

The 4-bit DLC field encodes payload length in bytes, 0 through 8 for classical CAN. Note that DLC values 9–15 are reserved in classical CAN (they mean something different in CAN FD, where they map to larger fixed payload sizes up to 64 bytes) — firmware parsing a mixed CAN/CAN FD bus needs to branch on the FDF bit before trusting DLC as a literal byte count.

Remote frames vs. data frames

A Remote Transmission Request (RTR) frame carries the same identifier and DLC as a normal data frame but no payload — it asks another node to transmit data for that ID. The RTR bit is recessive in a remote frame and dominant in a data frame, which matters directly in arbitration: if a data frame and a remote frame with identical IDs arbitrate simultaneously, the data frame wins because dominant beats recessive at that bit position.

Arbitration Mechanism

CSMA/CD-like arbitration on the CAN bus

CAN uses CSMA/CR — Carrier Sense, Multiple Access with Collision Resolution — rather than Collision Detection. Every node senses the bus before transmitting (carrier sense), multiple nodes can start simultaneously (multiple access), but instead of detecting a collision after the fact and backing off, CAN resolves the contention bit-by-bit during transmission itself, and the winner's frame proceeds uninterrupted.

Dominant vs. recessive bits (wired-AND logic)

This is the physical trick that makes it work. CAN defines two bus states: dominant (logical 0) and recessive (logical 1). Any node pulling the bus dominant overrides any number of nodes holding it recessive — it's a wired-AND (open-collector-style) topology on the differential pair. A node transmitting a recessive bit is also listening to the actual bus state; if it reads back dominant when it sent recessive, it knows another node is transmitting a higher-priority frame.

Priority assignment via identifier values

Lower numerical identifier value = higher priority, because during arbitration nodes transmit their ID MSB-first and a dominant bit (0) wins over a recessive bit (1) at any given position. An ID of 0x100 will always win arbitration against 0x200 the instant their bit patterns diverge, because the first differing bit of 0x100 is dominant where 0x200's is recessive.

Non-destructive arbitration principle

Arbitration is called non-destructive because the losing node doesn't corrupt the winner's transmission — it simply stops driving the bus and switches to receive mode, with zero bits lost from the winning frame and no retransmission needed by the winner. This is the core reason CAN gives strong real-time guarantees for high-priority messages even under bus load: the highest-ID message queued at any instant is guaranteed to win and transmit without interruption.

Handling simultaneous frame transmissions

Consider two nodes starting a frame at the same bit time, Node A with ID 0b00000000101 and Node B with ID 0b00000000110. Both transmit identical bits until bit 9 (counting from MSB), where A sends 0 (dominant) and B sends 1 (recessive). B reads back the actual bus state, sees dominant instead of its own recessive bit, immediately stops driving, and re-queues its frame for the next arbitration opportunity. A never even notices a contention occurred — its bits all read back as sent.

Bit Stuffing Algorithm

Purpose: preventing loss of bit synchronization

CAN nodes synchronize to bit edges — a sustained run of identical bits with no transition gives receivers nothing to resync against, risking clock drift between nodes accumulating into a sampling error. Bit stuffing guarantees a transition at least every 5 bits across most of the frame.

Five consecutive identical bits trigger stuffing

After any 5 consecutive bits of the same polarity (in SOF through CRC field, exclusive of the fixed-form fields), the transmitter inserts one bit of the opposite polarity — a "stuff bit" — that carries no data content and exists purely for synchronization.

Stuffing rules for dominant and recessive sequences

The rule is symmetric: five dominant bits in a row force an inserted recessive stuff bit; five recessive bits in a row force an inserted dominant stuff bit. This applies continuously, so a long run of alternating-but-not-quite data can still trigger multiple stuff insertions within one frame.

Bit destuffing on the receiver side

Receivers run the identical counting logic in reverse: after 5 consecutive identical received bits, the next bit is discarded as a stuff bit rather than treated as data. If a receiver counts 6 identical bits in sequence, that's a stuffing violation and it immediately flags a bit-stuffing error, one of CAN's five built-in error types.

Impact on frame length and bus utilization

Stuffing is non-deterministic in size — worst case it can add roughly 20% to frame length (stuff bits inserted every 4 real bits in a pathological bit pattern), which matters for bus-load calculations in J1939 and CANopen network design: never assume the nominal unstuffed frame length when sizing bus utilization margins; budget for worst-case stuffing overhead.

Error Detection and CRC

CRC field and polynomial calculation

Every frame carries a 15-bit CRC computed over SOF, arbitration, control, and data fields using a fixed generator polynomial defined in ISO 11898-1. The transmitter computes this CRC and appends it; every receiver recomputes it independently and compares.

Frame validation and ACK slot semantics

The ACK bit is unusual: the transmitter sends it recessive, and any receiving node that correctly validated the frame's CRC pulls it dominant. The transmitter checks whether the bus went dominant during that slot — this is how it confirms at least one node received the frame correctly, without any explicit acknowledgment frame being sent back.

Stuff bit errors vs. CRC errors

A stuff error means a receiver saw 6+ identical bits where a transition was mandated — it indicates a bus-level corruption, often a collision outside normal arbitration or severe noise. A CRC error means the frame was correctly bit-stuffed and structurally parseable but its content didn't hash to the transmitted checksum — pointing to data corruption within an otherwise electrically sound transmission. Separating these during debugging narrows the fault domain fast: stuff errors point to the physical layer or timing; CRC errors point to transient noise hitting the data field itself.

Frame rejection and bus recovery

Any node detecting an error (CRC mismatch, stuff violation, form error, bit error, or ACK error) transmits an error flag — six consecutive dominant bits — which itself violates the stuffing rule and forces every other node to also detect an error and discard the frame. The original transmitter automatically retries once the bus returns to idle. Each node tracks Transmit and Receive Error Counters; sustained faults push a node from Error-Active to Error-Passive and eventually Bus-Off, at which point it stops participating entirely until reset — a protection mechanism against one faulty node monopolizing or corrupting the bus.

Practical Implementation Considerations

Timing margins and bit rate selection

Each bit is divided into segments (Sync, Propagation, Phase 1, Phase 2) configured via the bit timing register on your CAN controller; propagation segment must accommodate worst-case round-trip delay across the physical bus plus transceiver loop delay. Consult your transceiver's datasheet for loop delay figures before committing to 1 Mbit/s over longer harnesses — undersized propagation segments are a classic cause of intermittent arbitration errors that only appear under thermal or voltage extremes.

Transceiver behavior during arbitration

Transceivers don't participate in arbitration logic — they just convert logic-level dominant/recessive into differential bus voltage and back. The wired-AND behavior is a property of the bus drive circuit (typically open-drain-like on CAN_H/CAN_L), not something firmware or the controller IP manages directly.

Handling of error frames and error states

Firmware should expose error counter and bus-state registers (Error-Active / Error-Passive / Bus-Off) to application logic rather than hiding them — a slow climb in the receive error counter over hours is often the earliest symptom of a degrading connector or ground fault, long before full Bus-Off occurs.

Clock synchronization requirements

CAN resynchronizes continuously using edges in the bit stream — SOF and every stuff bit serve this role — but each node still needs a reasonably accurate oscillator (typically within the tolerance specified in ISO 11898-1, check your controller's reference manual for the exact figure) since resynchronization only corrects small per-bit phase error, not gross clock mismatch.

CAN in Real-World Embedded Systems

Integration with protocol stacks (CANopen, J1939)

Raw CAN only defines frame transport; higher layers like CANopen (industrial automation) and SAE J1939 (heavy-duty vehicles) define how identifiers map to object dictionaries, PGNs, and node addressing on top of it. J1939 in particular packs priority, PGN, and source address into the 29-bit extended identifier, directly exploiting the arbitration mechanism described above to guarantee that diagnostic broadcasts don't starve safety-critical control messages.

Firmware-level frame assembly and parsing

In practice, frame assembly is handled by the CAN controller peripheral — firmware populates a transmit mailbox with ID, DLC, and data bytes, and the hardware handles SOF, stuffing, CRC, and arbitration autonomously. Parsing on receive is the inverse: read ID and DLC from the mailbox, validate DLC against expected length for that message type, and dispatch to the appropriate handler. The subtlety lives in filter configuration and interrupt/polling strategy, not in bit-level reconstruction, which hardware already did for you.

Determinism and real-time guarantees

Because arbitration always favors the lowest ID and is non-destructive, worst-case latency for any given message ID is calculable if you know the full set of IDs contending on the bus and their frame lengths — this is the basis of standard CAN schedulability analysis. That calculability is exactly why CAN remains the default choice where Industrial IoT (IIoT) vs. Consumer IoT Differences favor deterministic control-loop timing over the best-effort throughput models common in consumer connectivity stacks.

Testing and validation strategies

Bus analyzers that decode arbitration, stuffing, and CRC independently (rather than just showing payload bytes) are essential for diagnosing intermittent faults — inject known error conditions (forced bit flips, truncated frames) on a bench setup to confirm your error-handling firmware actually reaches Bus-Off and recovers as designed, rather than assuming it from the reference manual. As with most firmware validation work, this kind of test planning benefits from being tracked as explicit backlog items rather than ad hoc bench sessions — the same iterative discipline described in Agile Methodology: Sprint, Backlog, Scrum, Kanban applies well to building out a CAN fault-injection test suite incrementally across sprints.

Related reading

• CAN FD: Faster Data Phase, Up to 64 Byte Payload — the extended payload and faster data phase.