In the previous blog, we covered the basics of controller area network (CAN) and its role in modern embedded communication. In this sequel, we explore some of the advanced concepts that govern how CAN bus communication operates in practice — including Bit Stuffing, CAN frame types, error types, and synchronization. We also look at non-standard extensions available in modern CAN controllers.
Generally, all CAN modules that implement the controller area network protocol support classical CAN. They can receive and transmit both CAN base frames and CAN extended frames. Transmission and reception of CAN FD frames is optional. Classical CAN implementations do not support 29-bit identifiers. CAN 2.0B passive nodes were compliant with ISO 11898-1:2003 but are used rarely in practice. With that context, let us explore these advanced concepts in detail.
Bit Stuffing
Bit Stuffing is a key mechanism used in CAN bus communication to ensure synchronization of all nodes, even when transmitting consecutive bits of the same polarity. Understanding this is essential before diving into the specifics of CAN frame types and error handling.
During the transmission of a message on the controller area network bus, a maximum of five consecutive bits may have the same polarity. If this limit is reached, the transmitter inserts one additional bit of opposite polarity into the bit stream before transmitting further bits. This ensures there is always activity on the bus within six-bit intervals, preventing DC voltage build-up and keeping all nodes in sync.
Stuffing and De-stuffing
On the receiving end, the receiver checks the number of consecutive same-polarity bits and removes the stuffed bits from the bit stream in a process called de-stuffing. This interplay between stuffing and de-stuffing is a foundational element of reliable CAN bus communication.
CAN Frame Types
The controller area network protocol defines five distinct CAN frame types. Each serves a specific role in managing data transfer, error signaling, and bus access control. Understanding CAN frame types is essential for any engineer working with automotive or industrial CAN bus communication systems.
Embien's digital transformation services leverage deep expertise in CAN frame types and protocol stacks to build robust embedded communication solutions.
Data Frame (DF)
The Data Frame is the most common of all CAN frame types. It carries data from a transmitting node to one or more receiving nodes on the controller area network. The RTR (Remote Transmission Request) bit in a Data Frame is dominant, and a data field is always present.
Remote Frame (RF)
A Remote Frame enables a node to request data from another node on the CAN bus. There are two differences between a Data Frame and a Remote Frame in the context of CAN frame types: the RTR bit of a Remote Frame is recessive, and the data field is absent. Upon receiving a Remote Frame, the addressed node prepares and transmits the corresponding Data Frame.
Error Frame (EF)
Any node that detects an error on the controller area network transmits an Error Frame to signal the fault condition. The Error Frame consists of two fields:
- A superposition of ERROR FLAGS (6–12 dominant or recessive bits)
- An ERROR DELIMITER (8 recessive bits)
There are two types of error flags used in CAN bus communication:
Active Error Flag
When a transmitting node sends six consecutive dominant bits, the error is detected across the network and the node enters the Active Error state.
Passive Error Flag
When a transmitting node sends six consecutive recessive bits, the error is detected locally and the node enters the Passive Error state.
Every CAN node maintains two error counters — the Transmit Error Counter (TEC) and the Receive Error Counter (REC). When a transmitter detects an error in the transmitted frame, it increments TEC by 8. A receiver detecting an error increments its REC by 1. On successful transmission or reception, error counters are reduced by 1. Node behavior varies based on these counts:
- When TEC and REC < 128, the node is in the Active Error state and transmits an Active Error Frame that invalidates the frame globally.
- When 127 < TEC or REC < 255, the node is in the Passive Error state and transmits a Passive Error Frame without disrupting bus traffic.
- When TEC > 255, the node enters Bus-Off state and ceases all frame transmission.
In all cases, both transmitter and receiver reject erroneous frames and do not process them further. This layered error management is a core strength of the controller area network protocol.
Frames on the CAN Bus
Overload Frame (OF)
An Overload Frame is one of the five CAN frame types and is generated when a receiving node is overloaded — that is, it cannot handle incoming messages at the current rate. It contains two fields: an Overload Flag and an Overload Delimiter. The format is similar to an Error Frame, but error counters are not incremented. Overload Frames indicate that the transmitter requires a delay before the next data or remote frame, and they are rarely used in modern CAN controllers.
Inter Frame Space (IFS)
Data Frames and Remote Frames are separated from preceding and succeeding frames by a bit field called Inter Frame Space. IFS consists of three consecutive recessive bits. If a dominant bit follows the IFS, it is interpreted as the Start of Frame (SOF) bit of the next frame. IFS is an essential element of CAN bus communication timing.
Error Types in CAN Bus Communication
The controller area network defines five error types that nodes use to detect and signal faults during CAN bus communication:
Bit Error
Every transmitting node reads back the bits it places on the bus and compares each transmitted bit value with the received value. If a mismatch is detected, a Bit Error is raised.
Stuff Error
A Stuff Error is set when more than five consecutive bits of the same polarity are received. This violates the bit stuffing rule enforced across all CAN frame types.
CRC Error
The transmitting node includes a CRC value in the CRC field of the CAN frame. The receiving node independently calculates the CRC and compares it with the received value. A mismatch constitutes a CRC Error.
ACK Error
An ACK Error occurs when no acknowledgment is received by the transmitting node — meaning no other node confirmed successful reception of the frame. This is a vital integrity check in CAN bus communication.
Form Error
A Form Error is set when fixed-format fields in a received frame are violated. On the controller area network, no dominant bits are permitted in the CRC Delimiter, ACK Delimiter, EOF, or IFS fields.
CAN Data Link Layer
Data Link Layer Overview
The CAN data link layer handles framing, error detection, and medium access control. It implements the Logical Link Control (LLC) sublayer — which manages message filtering and overload notification — and the Medium Access Control (MAC) sublayer, which governs bit stuffing, data encapsulation, error detection, error signaling, and acknowledgment. All five CAN frame types operate within the CAN data link layer. Engineers building automotive or industrial products with Embien's automotive engineering services rely on a thorough understanding of the CAN data link layer to develop reliable communication stacks.
CAN Physical Layer
Physical Layer and Synchronization
The CAN physical layer defines the electrical characteristics of the bus, including the differential signaling on CAN High and CAN Low lines, termination resistors, and bit timing. Since there is no separate clock signal on the CAN bus, each node must synchronize independently.
The underlying transmission format used at the CAN physical layer is NRZ-5 (Non-Return-to-Zero with bit stuffing after 5 consecutive same-polarity bits). When the transmitting node sends the first bit of an SOF (Start of Frame), all receivers align themselves to this falling edge — a recessive-to-dominant transition. This initial alignment is called hard synchronization.
All subsequent falling edges within the CAN frame are used to re-synchronize nodes continuously. This is called soft synchronization or re-synchronization, and it occurs at every recessive-to-dominant transition to ensure transmitting and receiving nodes remain in sync throughout the frame. Proper synchronization at the CAN physical layer is fundamental to reliable CAN bus communication across long bus lengths and multiple nodes.
Additional Functions in the Controller Area Network
Modern controller area network implementations often include optional functions beyond the core specification:
- Single-shot transmission — Automatic re-transmission is disabled on error detection. Useful for TTCAN applications and diagnostic tools.
- Bus-monitoring mode — The node can receive Data and Remote Frames but does not acknowledge them or transmit Error and Overload Frames. Dominant bits are communicated internally within the CAN module.
- Restricted operation mode — Similar to bus-monitoring mode, but the node does acknowledge received Data and Remote Frames. Error counters are not incremented or decremented in this mode.
- TTCAN time master — A node designated as TTCAN time master must transmit the time-reference message; all other frame types must not be transmitted.
- Message time stamping — ISO 11898-1:2015 specifies an optional time-stamp function with resolutions of 8-bit, 16-bit, or 32-bit. The time-base value is captured at the reference point of each Data Frame and is readable after EOF (End of Frame).
- Arbitration lost capture — Other non-standardized options include readable error counters, configurable warning limits, and interrupt request generation.
If the CAN implementation permits changing the node configuration by software, configuration data such as bit-time configuration or operating mode must be locked against changes while CAN bus communication is active.
About Embien
Embien Technologies is a leading provider of product engineering services for the Automotive, Semiconductor, Industrial, Consumer, and Healthcare segments. Armed with in-depth knowledge of controller area network protocols and CAN bus communication, Embien has developed numerous CAN gateways, sensory nodes, and higher-layer protocol stacks including DeviceNet and CANOpen for industrial OEM customers. Our automotive experience spans Telematic units, In-Vehicle Infotainment systems, and Instrument Clusters with CAN interfaces.