A standard CAN FD message
The figure below shows the format of a standard CAN FD message. The start of a message is indicated by a leading dominant bit, followed by an 11-bit message key. The original r0 bit has now been renamed EDL (Extended Data Length) and indicates whether the message is a CAN 2.0 or CAN FD message. CAN FD includes a number of new control bits. The total overhead has increased from 44 bits (CAN 2.0) to 53 bits in CAN FD.
| Field name | Length (bits) | Purpose |
|---|---|---|
| SOF = Start-of-frame | 1 | Indicates the start of a message by pulling the bus to dominant ‘0’ |
| Identifier | 11 | A (unique) identifier for the data which also indicates the message priority |
| r1 = Reserved bit 1 | 1 | The reserved bit must be dominant ‘0’. Note: In CAN 2.0, this is the RTR bit; see the note below |
| IDE = Identifier extension bit | 1 | Dominant “0” for a standard (11-bit ID) CAN FD frame |
| EDL = Extended Data Length | 1 | Recessive ‘1’ for CAN FD; Dominant ‘0’ for CAN 2.0 Note: In CAN 2.0, this is reserved bit r0 |
| r0 = Reserved bit 0 | 1 | Reserved bit 1 must be a dominant ‘0’. |
| BRS = Bit Rate Switch | 1 | A recessive ‘1’ switches to accelerated transmission during the data phase; A dominant ‘0’ indicates no speed change during the data phase |
| ESI = Error State Indicator | 1 | Recessive ‘1’: Transmitter node is in Error Passive mode; Dominant ‘0’: Transmitter node is in Error Active mode |
| DLC = Data Length Code | 4 | Number of data bytes (0–64 bytes) as per table |
| Data field | 0 – 512 | Data being transmitted (number of bytes determined by the DLC field) |
| CRC = Cyclic Redundancy Check | 17 / 21 | Checksum across all preceding fields CRC = 17 bits for DLC ≤ 16 bytes and 21 bits for > 16 data bytes |
| CDL = CRC delimiter | 1 | Must be a recessive ‘1’ |
| ACK = Acknowledge slot | 1 | The transmitter sends a recessive “1” and (each) receiver can acknowledge successful reception with a dominant “0” |
| ADL = Acknowledge delimiter | 1 | Must be a recessive ‘1’ |
| EOF = End-of-frame | 7 | Must be a recessive ‘1’ |
The data field of a CAN message can contain between zero and 64 data bytes. The data field is followed by a 17-bit (≤16 data bytes) or 21-bit (>16 data bytes) CRC segment. This field is used by the receiver to verify the message. In the acknowledgement field, the sender of a message expects acknowledgement by receiving a signal from at least one receiving node within the network confirming that the message has been received without error. This acknowledgement is provided by the transmission of a dominant bit in the acknowledgement field by all (receiving) nodes within the network that have received the message without error. This acknowledgement is used exclusively to identify nodes that have transmitted errors.
Finally, the ‘end of message’ field indicates the completion and error-free transmission of a CAN message. As mentioned earlier, if a node detects an error, the message will be immediately interrupted by an error frame containing dominant ‘0’s.
An Extended CAN FD message
The figure below illustrates the format of an Extended CAN message. The key difference is that an Extended CAN message has a 29-bit Identifier field.
| Field name | Length (bits) | Purpose |
|---|---|---|
| SOF = Start-of-frame | 1 | Indicates the start of a message by pulling the bus to a dominant ‘0’ |
| Identifier A | 11 | Part A of a (unique) 29-bit identifier for the data, which also indicates the message priority; MSB bits 28 to 18 |
| SSR = Substitute remote request | 1 | A recessive ‘1’ enables a standard 11-bit CAN data message to win the arbitration against an extended CAN message |
| IDE = Identifier extension bit | 1 | Recessive ‘1’ for an extended (29-bit ID) CAN frame |
| Identifier B | 18 | Part B of a (unique) 29-bit identifier for the data, which also indicates the message priority; LSB bits 17 to 0 |
| r1 = Reserved bit 1 | 1 | Reserved bit must be a dominant ‘0’. Note: In CAN 2.0, this is the RTR bit; see note below |
| EDL = Extended Data Length | 1 | Recessive ‘1’ for CAN FD; Dominant ‘0’ for CAN 2.0 Note: In CAN 2.0, this is reserved bit r0 |
| r0 = Reserved bit 0 | 1 | Reserved bit 1 must be a dominant ‘0’. |
| BRS = Bit Rate Switch | 1 | A recessive ‘1’ switches to accelerated transmission during the data phase; A dominant ‘0’ indicates no speed change during the data phase |
| ESI = Error State Indicator | 1 | Recessive ‘1’: Transmitter node is in Error Passive state; Dominant ‘0’: Transmitter node is in Error Active state |
| DLC = Data length code | 4 | Number of data bytes (0–64 bytes) as per table |
| Data field | 0 – 512 | Data being transmitted (number of bytes determined by the DLC field) |
| CRC = Cyclic Redundancy Check | 17 / 21 | Checksum across all preceding fields CRC = 17 bits for DLC ≤ 16 bytes and 21 bits for > 16 data bytes |
| CDL = CRC delimiter | 1 | Must be a recessive ‘1’ |
| ACK = Acknowledge slot | 1 | The transmitter sends a recessive ‘1’ and (each) receiver can acknowledge successful reception with a dominant ‘0’ |
| ADL = Acknowledge delimiter | 1 | Must be a recessive ‘1’ |
| EOF = End-of-frame | 7 | Must be a recessive ‘1’ |
As the extended CAN message was added to the CAN standard at a later date, the extended message had to be adapted so that it could coexist with the standard message. This was achieved by dividing the 29-bit identifier into an 11-bit part A (the standard CAN message ID) and an additional 18-bit part B. A bit that was originally reserved was renamed IDE to distinguish between standard (IDE=’0’) and extended (IDE=’1’) messages. An additional reserved bit was added to the extended frame.
The SSR bit has a special function: it ensures that a standard 11-bit data message wins the arbitration against the equivalent 29-bit extended data message. Suppose two CAN nodes wish to send a message simultaneously with standard Id = 0h and extended Id = 0h; in that case, the node sending the standard Id = 0h message will win the arbitration.
Remote Request Frame
A CAN node can request an Identifier by sending a Remote Request message. This is a CAN message without a data field and with the RTR bit set to the recessive ‘1’. It is, of course, available in both standard and extended variants. A Remote Request message is best translated as “Identifier?”. The intention is that the ‘owner’ of the requested identifier responds by sending the corresponding CAN data message.
However, a Remote Request Frame does not, by its very nature, contain any data bytes, as it is intended to request data. Such a frame therefore does not take advantage of the benefits of CAN FD, as these are centred precisely on the transmission of data bytes. For this reason, CAN FD does not support any Remote Request Frames. The RTR bit has been renamed to r1 (Reserved 1) in CAN FD.
Bosch recommends using the CAN 2.0 Remote Request Format for Remote Requests. This is possible because CAN FD controllers are backwards-compatible with CAN 2.0. Incidentally, Remote Requests are an outdated concept and it is generally advised not to use them (anymore) in new implementations.
