Standard and Extended messages
Originally, CAN comprised only 11-bit identifiers. Bosch added the variant with a 29-bit identifier to support the SAE J1939 standard in America. This took place in 1991 and was introduced as CAN 2.0, later renamed CAN Classic. Today, we only have CAN Classic controllers. The standard therefore consists of two parts:
- 11-bit identifier, also known as CAN Standard and
- 29-bit identifier, also known as CAN Extended
Both ‘types’ may be used interchangeably, but they are distinct.
A standard CAN message
The figure below shows the format of a standard CAN data message. The start of a message can be recognised by a leading dominant bit, followed by an 11-bit identifier and a subsequent bit that distinguishes between a data frame and an RTR frame; see below.
| 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 | 11 | A (unique) identifier for the data, which also indicates the message priority |
| RTR = Remote transmission request | 1 | Dominant ‘0’ for a data frame; see also the Remote Frame below |
| IDE = Identifier extension bit | 1 | Dominant ‘0’ for a standard (11-bit ID) CAN frame |
| r0 = Optional Reserved bit | 1 | The reserved bit must be dominant ‘0’! A recessive ‘1’ indicates CAN FD format. |
| DLC = Data length code | 4 | Number of data bytes (0–8 bytes) |
| Data field | 0 – 64 | Data being transmitted (number of bytes determined by the DLC field) |
| CRC = Cyclic Redundancy Check | 15 | Checksum covering all preceding fields |
| 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 low ‘1’ |
| EOF = End-of-frame | 7 | Must be a recessive ‘1’ |
The data field of a CAN message can contain between zero and eight data bytes. The data field is followed by a 15-bit CRC segment. This field is used by the receiver to verify the message.
In the acknowledgement field, the sender of a message expects acknowledgement from all receiving nodes within the network. 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 of an 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 message
The figure below shows the format of an Extended CAN message. The key difference is that an Extended CAN message has a 29-bit Identifier field. This was primarily necessary to ensure that CAN complied with the J1939 standard.
| Field name | Length (bits) | Purpose |
|---|---|---|
| SOF = Start-of-frame | 1 | Indicates the start of a message by pulling the bus to 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’ allows 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 |
| RTR = Remote transmission request | 1 | Dominant ‘0’ for a data frame; see also the Remote Frame below |
| r0 = Optional Reserved bit | 1 | Reserved bit must be dominant ‘0’! Recessive ‘1’ denotes CAN FD format. |
| r1 = Optional Reserved bit | 1 | The reserved bit must be dominant ‘0’, but recessive ‘1’ is also accepted |
| DLC = Data length code | 4 | Number of data bytes (0–8 bytes) |
| Data field | 0 – 64 | Data being transmitted (number of bytes determined by the DLC field) |
| CRC = Cyclic Redundancy Check | 15 | Checksum covering all preceding fields |
| 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. In the extended frame, an additional reserved bit was added: the SSR bit. Consequently, the RTR bit has been moved behind the second part of the ID, so that this again makes logical sense for the arbitration of 29-bit IDs. The SSR bit also has another 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 message with standard Id = 0h 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, this depends on the type of CAN controller: CAN controllers with so-called Dual Port Memory will recognise the ID in their DP memory and autonomously send the associated data onto the bus. CAN controllers operating as UARTs can only pass on the RTR message, and the underlying software must then take the appropriate action. This is provided for, amongst other things, in the CANopen stack. Logically, the RTR bit in a Remote Request message is a recessive ‘1’. Consequently, such a message loses priority over the corresponding data message. After all, sending the data takes precedence over requesting it.
