Core Protocol Mechanisms of Controller Area Network (CAN)
Introduction

The Controller Area Network (CAN) protocol is renowned for its ability to provide reliable, real-time communication in complex embedded and automotive systems. This reliability is achieved through a set of core protocol mechanisms that govern how messages are transmitted, how timing is managed, how data integrity is preserved, and how nodes filter relevant information. Understanding these mechanisms is essential for anyone designing or troubleshooting CAN networks.
Arbitration


One of the most critical features of CAN is its arbitration mechanism. Arbitration is the process by which multiple devices, or nodes, determine which one is allowed to transmit a message when more than one device attempts to use the bus simultaneously. CAN uses a priority-based system, where each message is assigned a unique identifier. During arbitration, each device transmits its identifier bit by bit while simultaneously monitoring the bus. The CAN protocol defines two types of bits, dominant (logical 0) and recessive (logical 1). If a device transmits a recessive bit but detects a dominant bit on the bus, it immediately stops transmitting, as another device with a higher-priority (lower identifier) message is present. This bitwise arbitration ensures that the highest-priority message wins access to the bus without causing collisions or data loss, and all other devices defer their transmissions until the bus is free.
Bit Timing

Bit timing is another fundamental aspect of CAN communication. The bus rate, or baud rate, determines the duration of each bit on the network. For the arbitration mechanism to function correctly, the bit time must not be shorter than the round-trip signal propagation time across the network.

Each CAN message bit is divided into four programmable segments: the Synchronization Segment (Sync Seg), the Propagation Segment (Prop Seg), Phase Segment 1 (Phase Seg 1), and Phase Segment 2 (Phase Seg 2). These segments are measured in units called Time Quanta (TQ), which are derived from the oscillator frequency of the Microcontroller Unit (MCU). According to the ISO 11898-1 standard, the total bit time can range from 8 to 25 TQ. The precise configuration of these segments allows for synchronization and compensation for propagation delays, ensuring that all nodes interpret the bit stream accurately.
Bit Stuffing
To maintain synchronization and data integrity, CAN employs a technique known as bit stuffing. In this process, after every five consecutive bits of the same value (either all dominant or all recessive), the transmitter inserts a complementary bit into the data stream. For example, after five consecutive dominant bits (0s), a recessive bit (1) is inserted, and vice versa. This guarantees that there are enough transitions in the signal to allow receivers to maintain synchronization with the transmitter. Bit stuffing prevents the receiver from losing track of bit boundaries, which is crucial for reliable communication, especially in long or noisy networks.
Masks and Filters
Although every CAN node receives all messages broadcast on the bus, not every message is relevant to every node. To manage this, CAN controllers use masks and filters. Filters are configured to accept only messages with specific identifiers (where the message identifier bit value must match the filter value for acceptance), while masks are bitmasks that determine which bits of the identifier are compared during filtering (where a 1 means that the bit location is relevant and 0 means it will be ignored). This selective acceptance mechanism allows each node to process only the messages pertinent to its function, reducing unnecessary processing and improving overall system efficiency.

The truth table associated with the CAN Message example shows all the combinations of mask bit, filter bit, and message identifier bit values and whether each is accepted or rejected. If a particular mask bit location is 0, all filter bit and identifier bit values for that bit location will be accepted. Therefore, mask bit values have higher precedence than filter bits. Given a particular mask bit is 1, then only identifier bit values that match their associated filter bit values will be accepted.

Let’s walk through this example. This receiving node was programmed with a mask value of 0b111 1111 0101, so it will not care about the values in bit positions 3 and 1 because those values are 0. The node is also programmed with a filter value of 0b 011 0101 X1X0 where X can be a 1 or 0 because it won’t affect its acceptance criteria.
After the node’s receive buffer is loaded with 0b100 0101 1110 (0x35E), will this identifier value be accepted? Yes, because the receive buffer value matches the receive filter values. Note that the receive buffer values in bit positions 3 and 1 could have been any value since the receive mask register shows a 0 in those locations. As a result, identifier values of 0x354, 0x356, 0x35C and 0x35E will also be accepted.
Example 1: Accepting a Specific CAN ID
- User wants to accept only a single message identifier (0x88)
- Will use a mask of 0xFF to ensure that all bits are matched exactly
| Field | Binary Representation |
| ID = 0x88 | 1000 1000 |
| FILTER = 0x88 | 1000 1000 |
| MASK = 0xFF | 1111 1111 |
Since the mask is loaded with all ones, every identifier bit must match its corresponding filter bit value.
Example 2: Accepting a Specific CAN ID
- User wants to accept both message identifiers 0x88 and 0x89
- Will set the mask to 0xFE — this makes the least significant bit (LSb) 0 or a don’t care bit
| Field | Binary Representation |
| ID1 = 0x88 | 1000 1000 |
| ID2 = 0x89 | 1000 1001 |
| FILTER = 0x88 | 1000 1000 |
| Mask = 0xFE | 1111 1110 |
Since the last mask bit is 0, the filter ignores the LSb of incoming identifiers, allowing both 0x88 and 0x89 to be accepted.
Question: If you want to accept IDs 0x88 and 0x8A, which mask will accept both IDs?
| Field | Binary Representation |
| 0x88 | 1000 1000 |
| 0x8A | 1000 1010 |
- 0xFF (0b1111 1111)
- 0XFA (0b1111 1010)
- 0xFB (0b1111 1011)
- 0xFD (0b1111 1101)
Answer: D
Microchip Solutions
Microchip Technology provides a comprehensive suite of solutions to support these core CAN mechanisms. Their CAN transceivers, such as the MCP2551 and MCP2562, ensure robust physical layer communication. Standalone CAN controllers like the MCP2515, as well as integrated CAN peripherals in PIC®, AVR®, and SAM microcontrollers, offer flexible configuration of bit timing, masks, and filters. Microchip’s development tools, including MPLAB® X Integrated Development Environment (IDE) and CAN bus analyzers, further assist engineers in designing, testing, and optimizing CAN networks.
Summary
In summary, the core protocol mechanisms of CAN—arbitration, bit timing, bit stuffing, and message filtering—work together to provide a reliable, efficient, and scalable communication framework. These features enable CAN to meet the demanding requirements of automotive and industrial applications, and with the support of Microchip Technology’s hardware and software solutions, engineers can confidently implement and maintain robust CAN networks.