CAN-FD protocol overview

The CAN-FD protocol (CAN with flexible data-rate) is an extension of the classical CAN (CAN 2.0) protocol. CAN‑FD is the CAN 2.0 successor. It efficiently supports distributed real-time control with a very high-level of security. CAN-FD was developed by Bosch and standardized as ISO 11898-1:2015 (suitable for industrial, automotive, and general embedded communications).

Main features of the CAN-FD protocol are listed below:

• Compatibility with the CAN protocol: CAN-FD node is able to send/receive CAN messages according to ISO 11898-1
• Error-checking improvement, based on checksum field up to CRC 21 bits
• Prioritization of messages
• Guarantee of latency times
• Configuration flexibility
• Multicast reception with time synchronization
• System-wide data consistency up to 64 bytes per message
• Multimaster
• Error detection and signaling
• Distinction between temporary errors and permanent failures of nodes and autonomous switching off of defect nodes

The data sent is packaged into a message as shown in the figure below. A CAN-FD message can be divided into three phases:

1. a first arbitration phase
2. a data phase
3. a second arbitration phase

The first arbitration phase is a message that contains:

• a start of frame (SOF)
• an ID number and other bits, that indicate the purpose of the message (supplying or requesting data), and the speed and format configuration (CAN or CAN-FD)

The data transmission phase consists on:

• the data length code (DLC), that indicates how many data bytes the message contains
• the data the user wishes to send
• the check cyclic redundancy sequence (CRC)
• a dominant bit

The second arbitration phase contains:

• the receiver of acknowledgment (ACK) transmitted by other nodes on the bus (if at least one has successfully received the message)
• the end of frame (EOF)

  No message is transmitted during the IFS: the objective is to separate the current frame with the next.

The CAN-FD development responds to the need of communication networks that require higher bandwidth. This need is fulfilled by the CAN-FD having up to 64 bytes per frame and by its possibility to increase the bit rate to up to eight times faster during the data phase, and to go back to a normal bit rate during the second arbitration phase.

The data transfer integrity is ensured by:

• a CRC used to checksum a payload of up to 16 bytes based on 17 stage polynomial
• a 21-stage polynomial used to checksum the payload between 16 and 64 bytes

The main differences on frame architecture of CAN-FD compared to CAN 2.0 are illustrated on the figure below.

After identifier, CAN 2.0 and CAN-FD have a different action:

• CAN 2.0 sends an RTR bit to precise the type of frame: data frame (RTR is dominant) or remote frame (RTR is recessive).
• CAN-FD sends always a dominant RRS (reserved) as it only supports data frames.

The IDE bit is kept in the same position and with the same action to distinguish between the base formats (11-bit identifier). Note that the IDE bit is transmitted either as dominant or as recessive in case of extended format (29‑bit identifier).

In the CAN-FD frame, three new bits are added in the control field compared to CAN 2.0:

• Extend data length (EDL) bit: is recessive to signify the frame is CAN-FD, otherwise this bit is dominant (called R0) in CAN 2.0 frame.
• Bit rate switching (BRS): indicates whether two bit rates are enabled (for example when the data phase is transmitted at a different bit rate to the arbitration phase).
• Error state indicator (ESI): indicates if the node is in error-active or error-passive mode.

The last part of the control field is data length code (DLC), that has the same position and same length (4 bits) for both CAN 2.0 and CAN-FD. The DLC function is the same in CAN-FD and CAN 2.0, but with small changes on CAN-FD regarding the payload data length codes. (details in the table below). CAN-FD allows extended frames to be sent of up to 64 data bytes in a single message while CAN 2.0 payload data is up to 8 bytes.

The network bandwidth is improved by the increase of data fields that carry the payload data, as there is less need for multi packet handling. Consequently, the message integrity is enhanced by adding more bits for the CRC field:

• If the payload data is up to 16 bytes, CRC is coded in 17 bits.
• If the payload data is higher than 20 bytes, CRC is coded in 21 bits.

In addition, to ensure the CAN-FD frame robustness, the CRC field is supported by stuff bit mechanism.

The table below summarizes the main difference between CAN-FD and CAN 2.0. The main features that provide an improvement on CAN‑FD compared to CAN 2.0 are the increase of data payload and the higher speed ensured by the BRS, EDL and ESI bits available in CAN-FD.