In the last blog, we have covered the basics of CAN communication. Now, we will see about some of the advanced concepts involved such as Bit Stuffing, frame types, error types, Synchronization etc. We will also look into some of the non-standard extensions available in modern CAN controllers.

Generally, all CAN modules support the classical CAN protocol. It can receive and transmit both CAN base and the CAN extended frames. The transmission and reception of CAN FD frames is optional. Classical CAN Implementation do not support 29-bit identifiers. CAN 2.0B passive nodes were compliant with ISO 11898-1:2003, but it used very rarely. In this context, let us explore some of other concepts in detail.

Bit Stuffing

Bit Stuffing is used to ensure the synchronization of all nodes even when transmitting consecutive information with same value either 1 or 0.
During the transmission of message, a maximum of five consecutive bits may have the same polarity. In this case, the transmitter will insert the one additional bit of opposite polarity into the bit stream before transmitting the further bits. This will ensure that there is always some activity in the bus with in 6-bit intervals and hence avoid DC Voltage build up as well as being in sync with the transmitter.

Stuffing and De-stuffing

On the receiving end, similarly the receiver also checks the number of bits of same polarity and removes the stuffed bits again from the bit stream in a process called de-stuffing.

CAN Frame Types

There are 5 types of frames in CAN protocol;

Data Frame (DF):

Carries Data from transmitting node to receiving node.

Remote Frame (RF):

Some times, a node might want to request some data from another which is made possible by Remote frame.
There are two differences between data and Remote frames.
RTR field of a data frame is dominant and RTR field of remote frame is recessive.
In data frame format data field is present, whereas in Remote frame format data field is absent.

The receiver will understand that transmitter is requesting some date and then prepares and sends the Data frame based on the protocol.

Error Frame (EF):

This type of frame is transmitted by any node to signal error.
The error frame consists of two different fields in CAN.
superposition of ERROR FLAGS (6–12 dominant/recessive bits)
ERROR DELIMITER (8 recessive bits).
There are two types of error flags:

Active Error Flag

When the Transmitting node transmitted six dominant bits, the error will be detected in network and the error sate called active error flag.

Passive Error Flag

When the Transmitting node transmitted six recessive bits, the error will be detected in network and the error sate called passive error flag.

Now let us see, how the CAN manages error states. In every CAN node, there are 2 error counters – Transmit Error Counter (TEC) and Receive Error Counter (REC). When the transmitter detects an error in the transmitted frame, it increments the TEC by 8. A receiver detecting an error will increment its REC by 1. On successful transmission/reception the error counters are reduced by 1.
Based on the error counts, the node behavior varies.

  • By default, the Active Error frame will be transmitted on the bus, when TEC and REC < 128. Thus, it will invalidate the frame globally.
  • But when 127 < TEC \ REC > 255, the passive Error frame will be transmitted on the bus, without affecting the bus traffic.
  • Finally, the node enters into the Bus off state, when TEC > 255. If node enters into the bus off state then no frames will be transmitted.

In any case, both transmitter and receiver reject the erroneous frames completely and do not process it any further.

Overload Frame (OF):

Overload frame contains two fields such as Overload flag and Overload Delimiter.
The over load frame will be generated, when the receiving node is overloaded – i.e. it is not able to detect and receive the incoming messages. The format is very similar to Error Frame but without the error counters incrementing. An Overload frame indicates that its transmitter require delay before receiving next data or remote frame and is mostly not used in modern CAN controllers.

Inter Frame Space (IFS):

Data frames and remote frames are separated from preceding frames and succeeding frame by a bit field called interframe space. It consists of three consecutive recessive bits. Following that, if a dominant bit is detected, it will be regarded as the “Start of frame” bit of the next frame.

Frame on CAN BUS

Error Types

There are 5 types of error in CAN protocol.

Bit error:

Every node reads back, bit by bit from the bus during transmitting the message and then compares the transmitted bit value with received bit value. If bit received does not match with bit sent, then Bit error is said to be occurred.

Stuff error:

Set when more than five consecutive bits of same polarity are received in receiving node.

CRC error:

A transmitted always transmits the CRC value in the CRC field of CAN frame. The receiving node also calculates the CRC value using same formula and compares with received CRC value. If receiving node detects mismatch between calculated CRC values and received CRC value then it is called CRC error.

ACK error:

Occurs when no acknowledgment is sent by receiving node or no acknowledgment received in transmitting node.

Form error:

Set when fixed format fields in receive frame is violated. No dominant bits are allowed in CRC delimiter, ACK delimiter, EOF and IFS.

Synchronization and Re-synchronization

As there is no separate clock signal on the CAN bus, the node itself need to synchronize on the bus. For that reason, the underlying transmission format is NRZ-5 coding.
When the transmitting node sends CAN frame it consists the first bit of SOF (start of frame). All the receivers align themselves to this falling edge (recessive to dominant) after the period of bus idle. This mechanism is called hard synchronization.
After subsequent falling edges on the CAN frame are used to re-synchronize the nodes on bus and it is called soft synchronization. This resynchronization happens continuously at every falling edge (recessive to dominant transition) to ensure transmitting and receiving nodes stay in sync.

Additional functions

Some CAN protocol implementations offer optional functions that may or may not be a part of CAN specification. These include, for example, the single-shot transmission of data frames. This means that the automatic re-transmission in case of detected errors is disabled. This is useful for TTCAN add-ons and some tool applications.
Another option generally available is the bus-monitoring mode. The node can receive data and remote frames, but doesn’t acknowledge them and also doesn’t send error and overload flags. Nevertheless, these dominant bits are communicated internally in the CAN module.
In another optional restricted operation mode, the CAN module behaves equally, but it acknowledges received data and remote frames. The error counters are not incremented and decremented in this mode. If a node is the TTCAN time master, it must be able to transmit the time-reference message; other frames must not be transmitted.
For some applications, message time stamping is required. ISO 11898-1:2015 specifies that the optional time-stamp function features resolutions of 8-bit, 16-bit, or 32-bit. The time-base value is captured at the reference point of each data frame and it is readable after EOF (end-of-frame). Other (not standardized) optional functions include readable error counters, configurable warning limits, interrupt request generation, and arbitration lost capture.
If the CAN implementation allows changing the configuration of a node by software, the configuration data (e.g. bit-time configuration or operating mode) needs to be locked against changes while CAN communication is ongoing.

Armed with details of CAN communication, we will now attempt to understand general configuration of a CAN node for transmission and reception with examples from a real controller.

About Embien

Embien Technologies is a leading provider of product engineering services for the Automotive, Semi-conductor, Industrial, Consumer and Health Care segments. Working with OEMs in Industrial segments, we have developed numerous gateways, sensory modes on top of CAN network and protocols such as DeviceNet, CANOpen etc. Our Automotive experience enabled us develop Telematic units and In-vehicle Infotainment systems, Instrument clusters with CAN interfaces.

In the past, electronic devices in vehicles are connected via point to point wiring systems. Automotive manufacturers started using more and more electronics in vehicle, which resulted in bulky wire harnesses that were heavier and expensive too. Then they introduced a specialized internal communication network called vehicle bus that interconnects electronic devices inside a vehicle. Vehicle bus reduced the wiring cost, weight and complexity.

At present there are several types of network types and protocols used in vehicles by various manufacturers. Most common vehicle bus protocols includes,

  1. CAN
  2. LIN
  3. FlexRay
  4. MOST
  5. DC-BUS
  6. IEBUS
  7. J1850
  8. ISO 9141-1/-2
  9. D2B – Domestic Digital Bus
  10. VAN

Among the various bus protocols, CAN emerged as the standard in-vehicle network and it became the international standard known as ISO 11898. Bosch originally developed the Controlled Area Network (CAN) and it has been adopted by the automotive industry. Several higher level protocols have been standardized on CAN such as CANopen and DeviceNet which are commonly used for industrial communications. CAN is also adopted specifically for classes of vehicles such as J1939 for commercial vehicles and ISO11783 for agricultural vehicles.

In this blog, we will describe in detail about the CAN protocol as an in-vehicle network.

CAN Bus – Basics

CAN bus is an inexpensive, robust vehicle bus standard designed for multiple CAN device communications with one another without a host computer. CAN is also called as multi-master serial bus and the CAN devices on bus are referred to as nodes. Two or more nodes are required on the CAN network to communicate. All nodes are connected to each other via a two wire bus (CAN H and CAN L) and the wires are 120ohms nominal twisted pairs. Termination resistor commonly 120 ohms is must in each node in order to suppress the reflections as well as return the bus to its recessive or idle state.

Following is the block diagram of the CAN bus architecture,

CAN bus architecture

Architecture of CAN bus

Each node in the CAN bus requires the following

  1. Transceiver – It converts the data from the CAN controller to CAN bus levels and also converts the data from CAN bus levels to suitable level that the CAN controller uses.
  2. CAN controller – They are often an integral part of the microcontroller that handles framing, CRC etc.
  3. Microcontroller – It decides what the received messages mean and what messages it wants to transmit.

The transceiver drives or detects the dominant and recessive bits by the voltage difference between the CAN H and CAN L lines. The nominal dominant differential voltage is between 1.5V to 3V and recessive differential voltage is always 0V. CAN transceiver actively drives to the logical 0 (dominant bits) voltage level and the logical 1 (recessive bits) are passively returned to 0V by the termination resistor.  The idle state will always be in the recessive level (logical 1).

Individually, CAN H will always be driven towards supply voltage (VCC) and the CAN L towards 0V when transmitting a dominant (0). But in practical case, supply voltage (VCC) or 0V cannot be reached due to transceiver’s internal diode drop. CAN H/L will not be driven when transmitting a recessive (1) where the voltage will be maintained at VCC/2.

The following figure depicts the block diagram and real time capture of the CAN signals.

Voltage level of CAN bus lines

CAN Bus – Voltage Levels


Capture of CAN bus signals using DSO

Real time capture of CAN bus signals

CAN Physical Layers – Types

CAN has different physical layers which classifies the certain aspects of the CAN network such as signaling scheme, cable impedance, maximum data rates, electrical levels, etc. Following are the most commonly used physical layers,

1. High Speed CAN

High speed CAN is implemented with two wires and allows communication at data rate up to 1Mbits/s. It is also named as ISO 11898-2. Antilock brake system, engine control modules, emission systems uses high speed CAN.


CAN with Flexible Data rate is the next generation of high speed CAN communication with improved standards for higher data rates. CAN FD overcome the bandwidth limitation problems by allowing data rates higher than 1Mbits/s while also increasing the support of payloads up to 64 bytes in a single message.

3. Low speed/fault-tolerant CAN

Low speed/fault tolerant CAN networks are also implemented with two wires and can communicate at a data rate of up to 125Kbits/s with fault tolerant capabilities. They are also named as ISO 11898-3 and found in devices where wires that have to pass through the doors of the vehicle which have light stress that is inherent to opening and closing a door.

4. Single wire CAN

Single wire CAN interface have lower data rate up to 33.3Kbits/s and also named as SAE-J2411. The devices that do not require high performance like seat and mirror adjuster use Single wire CAN interface.

Transceivers are available for each type of CAN physical layer and it is one of the important criteria while choosing the transceiver. Many semiconductor manufacturers provide CAN transceivers including NXP semiconductors, Texas instruments, STMicroelectronics, Maxim Integrated, Infineon Technologies and Linear Technology.

Apart from generic CAN transceivers, there are special purpose transceivers such as galvanically isolated transceivers that are used for providing the isolated interface between a CAN protocol controller and the CAN bus. For galvanic isolated design, there is a need for isolated power supply and hence the design becomes more complex and costlier.

Transceivers with option for direct interface with the microcontroller are also available which reduces the requirement of external buffer ICs for voltage compatibility.

CAN terminologies

Following are some CAN bus terminologies that are useful to understand how CAN bus communication works. 

1. CAN Frame and fields descriptions

Devices in CAN network send data in packets called frames. Following image depicts frame format,

CAN Protocol frame format

Frame Format of CAN protocol

SoF – Start of Frame bit – indicates the beginning of a message with a dominant (logic 0) bit

Arbitration ID – identifies the message and indicates the message’s priority. Frames come in two formats — standard, which use an 11-bit arbitration ID, and extended, which uses a 29-bit arbitration ID

IDE – Identifier Extension bit – This bit allows differentiation between standard and extended frames

RTR – Remote Transmission Request bit – This bit is used to differentiate a remote frame from a data frame. A logic 0 (dominant bit) indicates a data frame. A logic 1 (recessive bit) indicates a remote frame

DLC – Data length code – It indicates the number of bytes the data field contains

Data Field – contains 0 to 8 bytes of data and up to 64 bytes of data for CAN-FD (Flexible Data rate)

CRC – Cyclic Redundancy Check – The CRC field is used for error detection. It contains 15-bit cyclic redundancy check code and a recessive delimiter bit.

ACK – Acknowledgement slot – any CAN controller that correctly receives the message sends an ACK bit at the end of the message. The transmitting node checks for the presence of the ACK bit on the bus and reattempts transmission if no acknowledge is detected

2. Bus Arbitration

Arbitration is the process in which two or more CAN controller agrees on who is to use the bus. It is of very important for the really available bandwidth for data transmission and this is the base for CAN bus communication. Arbitration process is performed over the arbitration ID.

3. Bit stuffing

Bit stuffing is a practice used to guarantee enough edges in the NRZ (Non-Return to Zero) bit stream to maintain synchronization. After five identical and consecutive bit levels have been transmitted, the transmitter will automatically inject (stuff) a bit of the opposite polarity into the bit stream. Receivers of the message will automatically delete (destuff) such bits. If any node detects six consecutive bits of the same level, a stuff error will be flagged.

How CAN communication works?

As mentioned early, CAN is a Peer-to-Peer network in which there is no master that controls the transmission between nodes. When any CAN node is ready to transmit data, it should undergo a process called message arbitration. In this process, CAN node will check to see if the bus is idle and starts the transmission once it is idle. This will also trigger other CAN nodes in the bus and hence results in two or more nodes starting a message at a same time which results in a conflict. The conflict is resolved in the following methods,

  1. The transmitting node monitors the bus while they are sending data
  2. If any node detects a dominant level (logical 0) while sending a recessive level itself, it will fail in the arbitration process and quits immediately will start acting as a receiver.
  3. This arbitration process is performed while sending the arbitration ID field of the CAN frame and at the end, only one transmitter is left on the bus i.e. the node with the highest priority (lowest arbitration ID) will pass the arbitration.
  4. Then the node which has won the arbitration will continue message transmission as if nothing had happened.
  5. Other receiving node can decide if a message is relevant or if it should be filtered using a combination of hardware and software filters.
  6. This process is continuous and other nodes will transmit their messages when the bus has become available.
Bit Wise Arbitration process

CAN protocol – Bit Wise Arbitration

With this blog, we have covered all the basics of CAN communication including the physical layers, Data link as well as arbitration mechanisms. In the upcoming blog, we will explain more on software perspective about configuring a CAN controller for operation and handling message flow.

About Embien

Embien Technologies is a leading provider of product engineering services for the Automotive, Semi-conductor, Industrial, Consumer and Health Care segments. Embien has successfully executed many projects like Android based Auto infotainment system, GUI for TFT based instrument clusters, vehicle tracking devices, etc. Embien also offers a set of solutions such automotive grade BLE module (eStorm-B1), CAN to BLE gateway, CAN to RS232/RS485 gateway, LIN to BLE gateway, Sparklet GUI library that can be used to shorten automotive product development costs and time significantly.