What is CAN protocol ?

The Controller Area Network (CAN) is a serial communications protocol which supports distributed real-time control with a very high level of security and efficiency. 

Where is CAN Protocol Used ?

CAN is extensively used (but not restricted) in the automotive industry for the automotive electronics precisely in the engine control units (ECUs), for various applications involving sensors, anti-skid systems etc. The numerous ECU functions used in an automotive vehicle are managed by microcontrollers. To establish a communication between the microcontrollers and devices with each other’s applications without needing a host computer, a bus architecture known as CAN is robustly designed. 

How does CAN communicate?

CAN is a message- based protocol and for each device, the data in a frame is transmitted sequentially. The message onto the bus is transmitted serially using a Non-Return-to-Zero (NRZ) format. 

CAN Protocol : Theory of Operations

Bit rate: The bit rate of a CAN bus in a given system is uniform and ranges up to maximum 1 Mbps (excluding CAN-FD). CAN-FD could have a variable bit rate in a given system and ranges up to maximum 5-8 Mbps.

Broadcast: CAN is a broadcasting type of communications protocol, in which the concept of ‘Master’ and ‘Slave’ is not present. Any device having an update over a specific activity from any application could transmit the corresponding frame and every other device on the bus could read this frame.

Arbitration: Since CAN is a broadcasting type of communications protocol, multiple devices tend to communicate at the same time. During such a condition, conflict on the bus is inevitable. In order to solve this type of problem, bitwise arbitration is adopted. Whichever device wins the arbitration, gets to communicate and others back off.

Error Detection: All CAN nodes are implemented with powerful measures for error detection, signaling and self-checking, and these measures are:

  • Monitoring (the bit levels of the data to be transmitted in will be continuously compared by the transmitter with the bit levels detected on the bus).
  • Cyclic Redundancy Check (CRC) – CRC is adopted to ensure that the data in the frame is received flawlessly.
  • Bit stuffing – After every 5 consecutive homogeneous bits a bit with an opposite polarity is introduced. This is called bit stuffing.

Now let’s get into the CAN frame formats and the way they look.

CAN Frames Format :

The message transfer is done through four types of frames, and they are: 

Data frames: Carries the data between transmitter and receiver

Remote frames: A bus unit can request the transmission of a data frame with the same Identifier by sending this remote frame to the transmitter.

Error frames: When a bus error is detected, an error frame is transmitted.

Overload frames: An overload frame is transmitted to provide an extra delay between frames (a standard amount of delay is provided by Inter frame space) during multiple frames transmission.

Each Data frame and Remote frame has two different types of frame formats, and they are, Standard frame and Extended frame.

Alright, pictures speak more than words! Let us show the frames


These fields are same for both Data and Remote frames. The next fields are as shown in the below figure.

After all these fields, it is End-of-Frame field which consists of seven consecutive 1’s, indicating the end of transmission.

Seven consecutive 1’s? What about bit stuffing then?

Well, bit stuffing is done only till the CRC-Delimiter field. The remaining fields are fixed in a frame. Hence, no bit stuffing is done to the Acknowledgement field and End of frame field.

Okay, now what’s the difference between Standard frame and Extended frame? As well as between Data frame and Remote frame?

One at a time; The only difference between Standard and Extended frames are that the identifier is of 29-bits in Extended frames whereas, 11-bits in Standard frame formats. The 29-bits are categorized into two ID fields, first 11-bits are as same as in the Standard frame and next 18-bits in another field. Below figure shows the difference between the two frames.

The SRR field is Substitute Remote Request, and it is transmitted as recessive.

Well, now with Data frame and Remote frame. Data frame is as shown in the above figure. Remote frame is same as Data frame except that the Data field is not present. So, it comprises of SOF, Arbitration field, Control field, CRC field, ACK field and EOF. 

Great! Next, what’s with that CAN-FD?

CAN-FD stands for CAN Flexible Data rate. This was introduced to increase the bandwidth on the bus by increasing the bit rate. Meaning, the bit rate on a given system during the frame transmission could change to a higher speed.

Oh, that’s nice! What about the frame structure?

CAN-FD has a similar frame structure to that of normal CAN, and two different types of frame formats as that of normal CAN, standard and extended frames, but there are no Data frame and Remote frame concept here. The below figure gives a clear idea about the same.

The only fields that are different from normal CAN are, EDL, BRS, and ESI

The CAN FD extended frame format consists of 29-bit identifier and an SRR field which is recessive one bit. And the rest of the fields remain same as that of CAN FD standard frame format.

CAN Protocol Challenges in Debug

Well, the challenges during the debug are:

  1. Identifying different types of errors on the CAN bus
  2. Capture time for long data bytes and error checking for the same

About the Author :

Sumukha Bharadwaj is an FPGA Design Engineer in Prodigy Technovations. He graduated from K S school of Engineering and Management in 2015 with a Bachelor’s degree in Electronics & Communication Engineering. He also completed his Master of Engineering, Information Technology from SRH Hochschule Heidelberg.

About Prodigy Technovations :

Prodigy has developed state of the art Protocol analyzer to debug various Protocols. The protocol analyzers ranges from I2C,SPI ,QSPI ,I3C and UFS Plus many other protocols on the serial bus.