CAN data link layers in some detail
The CAN data link layer comprises two protocols: Classical CAN introduced in 1986 and implemented for the first time in 1988 and CAN FD launched in 2012 and internationally standardized in 2015 in ISO 11898-1. For a transitional period there are also non-ISO compliant implementations on the market. They are application-transparent, meaning they can be used for software development and designing prototype networks. However, CiA doesn’t recommend using them for serial production.
The structure of CAN data frames are the same for Classical CAN and CAN FD, just the field details are different
The two CAN data link layer protocols have some common features. Any node has the right to request transmission rights at any time. The necessary bus arbitration method to avoid transmission conflicts is the same: Frames with the highest assigned identifier get bus access without delay. All frame types (data, remote, error, and overload frame) are transmitted in broadcast. The data frame structure comprising several fields is the same.
One of the unique features of the CAN data link layers is that all single-bit errors are detected. Multi-bit errors are detected with a high probability. In order to provide data consistency in all nodes, local errors are globalized. Additionally, the fault confinement implemented in the CAN data link layers precludes a single node from corrupting the communication of the others permanently.
The Classical CAN protocol uses just one bit-rate in the arbitration and the data phase. The transmission speed is limited to 1 Mbit/s for short networks (theoretically up to 40 m). However the achievable bit-rate depends on the network length and the used physical layer elements such as cable, connector, and transceiver. The payload, the data field, is limited to 8 byte.
The CAN FD protocol allows payloads up to 64 byte. Additionally, it supports an optional second bit-rate for the data-phase. The limitation of the speed in the arbitration phase is the same as for Classical CAN. In the data phase, the speed is limited by transceiver characteristic, the oscillator tolerance, and the topology (ringing). Data phase bit rates up to 8 Mbit/s are realistic when using a bus-line topology with very short, not terminated stubs.
Data (and remote) frame structure
The data frames in Classical CAN and CAN FD comprises the same fields. The remote frame, only available in Classical CAN, has the same field structure as the data frame, but without a data field.
The SOF (start-of-frame) field is a fixed 1-bit field with a dominant bit level. It is followed by the arbitration field, which contains mainly the identifier bits and some protocol bits indicating the length of the CAN-ID and reserved bits. The next field is the control field with the information on the length of the data field (four data length code bits). Additionally, it provides some control bits, e.g. the FDF (FD format) bit distinguishing the two data link layer protocols, Classical CAN and CAN FD. The payload is in the data field. In Classical CAN, it features up to 8 byte and in CAN FD it can be up to 64 byte long. The following CRC field comprises a cyclic redundancy checksum (CRC) and in CAN FD an additional stuff-bit counter. The ACK (acknowledge) field is made of two bits. It is used to indicate a correct reception of the message. The last fields are the 7-bit EOF (end-of-fame) with fixed format (recessive bit-level) and the 3-bit IMF (intermission field) separating the frame from the next one.
Data (and remote) frame formats
The CAN data link layers distinguish between base frames (11-bit CAN-ID) and extended frames (29-bit CAN-ID). Base frames have a dominant IDE (ID extension) bit. This is why they win bus-arbitration against extended frames with the very same first bit-pattern. In order to distinguish between Classical CAN and CAN FD frames, the r1 reserved bit is transmitted recessively in CAN FD frames. Of course, this violates the Classical CAN specification. This means that legacy CAN controller chips destroy CAN FD communication. However, there are some migration paths that let you use legacy CAN implementations in CAN FD networks.
- The ISO 11898-1 standard introduces four different formats:
- CBFF: Classical base frame format with 11-bit IDs
- CEFF: Classical extended frame format with 29-bit IDs
- FBFF: FD base frame format with 11-bit IDs
- FEFF: FD extended frame format with 29-bit IDs
The formats differ in the control field (additional bits in FD frames), the data field length (Classical data frames are limited to a maximum of 8 byte, while FD data frames allow up to 64 byte), and the CRC field (different polynomials and additional safeguards for FD frames). Remote frames are not supported by the CAN FD protocol. CiA doesn’t recommend using remote frames. Remote frames request a data frame with the very same CAN-ID.
Bus arbitration method
Both CAN data link layers, Classical CAN as well as CAN FD, provide multi-master capability. This means that any node is allowed to access the bus at any time, if it is idle. If several nodes want to communicate at the same moment, the message with the highest priority wins the bus arbitration and gets the right to transmit. The system designer assigns the priority uniquely to each message. The CAN identifier (CAN-ID) as part of the message indicates the priority. The lower the number of the CAN-ID, the higher the priority. The value of “0” is the highest priority.
Network access conflicts are resolved by a bit-wise arbitration of the CAN-ID. All connected nodes observe the bus level bit-for-bit. There are two bus levels: dominant and recessive. The dominant level overwrites the recessive level equivalent to a wired-AND circuitry. All nodes transmitting a recessive level and detecting on the bus-lines a dominant level lose bus arbitration and transit into listening mode.
After the transmission of all CAN-ID bits, only one node is still in transmission mode. All other nodes are consuming the transmitted message. There is one exception: If a remote frame and the requested data frame using the very same CAN-ID are competing on the transmission right, the data frame wins due to the additional RTR (remote transmission request) bit, which also belongs to the arbitration field. This means that the data frame wins the bus arbitration against the corresponding remote frame.
Remote frames are not supported in the CAN FD protocol. The RTR bit is named RRS (remote request substitution) and is always transmitted dominantly.
Error detection methods
The CAN data link layers are very reliable. All single-bit errors are detected. Multi-bit errors are detected with a high probability; the CAN FD protocol is even a little bit more reliable than the Classical CAN protocol.
The CAN data link layers comprise five error detection mechanisms. Unlike other communication systems, they do not use acknowledgement messages but instead signals any occurring errors. For error detection the CAN protocols implement three mechanisms at the message level:
- Cyclic Redundancy Check: The CRC safeguards the information in the data and remote frame by adding redundant check bits at the transmission end. At the receiver end, these bits are re-computed and tested against the received bits. If they do not agree, a CRC error has occured. There is an additional safeguard in the CAN FD protocol: the stuff error counter with parity bit protection.
- Frame check: This mechanism verifies the structure of the transmitted data and remote frame by checking the bit fields against the fixed format and the frame size. Errors detected by frame checks are designated „format errors“.
- ACK errors: As mentioned above, all nodes acknowledge received data and remote frames by positive acknowledgement (driving the bus to dominant bit-level during the ACK bit). If the transmitter does not see a dominant bit-level during the ACK bit, this can either mean that there is a transmission error which has only been detected by the recipients, that the ACK field has been corrupted, or that there are no receivers.
The CAN protocol also implements two mechanisms for error detection at the bit level.
- Monitoring: The ability of the transmitter to detect errors is based on the monitoring of bus signals. Each node, which transmits and also observes the bus level and thus detects differences between the bit sent and the bit received. This permits reliable detection of all global errors and errors local to the transmitter.
- Bit stuffing: The coding of the individual bits is tested at bit level. The bit representation used by CAN is NRZ (non-return-to-zero) coding, which guarantees maximum efficiency in bit coding. The synchronization edges are generated by means of bit stuffing, i.e. after five consecutive equal bits the sender inserts a stuff bit into the bit stream with the complementary value, which is removed by the receivers. The code check is limited to checking the adherence to the stuffing rule.
Detected errors are indicated by means of an Error Frame. It consists of the Error Flag made of six bits of the same bit-level and eight bits of recessive value called Error Delimiter.
The CAN data link layers detect all communication errors with a very high probability. A node detecting an error condition sends an Error Flag and discards the currently transmitted frame. All nodes receiving an Error Flag discard the message, too. In case of local failures, all other nodes recognize the Error Frame sent by the node(s) that detected it and sent by themselves a second time, which results in an eventually overlapping Error Frame. The active Error Frame is made of six dominant bits and an 8-bit recessive delimiter followed by the IMF. This local error globalization method guarantees network-wide data consistency, an important feature in distributed control systems.
If all errors are detected with a very high probability, permanent errors may lead to an unacceptable delay in transmitting messages. In the worst-case, all communication is aborted by means of Error Frames. In order to avoid this, the CAN protocol introduces two error counters: one for received messages (REC) and one for transmitted messages (TEC). They are increased and decreased according to the rules as specified in ISO 11898-1, the standard of the CAN data link layer protocols.
If one of the counters reaches 127, the node transits to error passive state. In this state, the node transmits passive Error Flags made of six recessive bits. This flag is overwritten by dominant bits of a transmitting node. This means that an error passive node can’t inform the other nodes about an incorrectly received frame. This is a critical situation from the viewpoint of the system. If a transmitting node permanently produces Error Flags, this would also delay and in the worst-case (high-prior message) block the other communication. Therefore, the node is forced into bus-off state, if the TEC reaches 256. In bus-off state, the node transmits only recessive bit-level. To transit to the error active state requires two conditions: a reset and the occurrence of 128 by 11 bit-times. This means that the remaining nodes are able to transmit 128 data frames before the node in bus-off recovers and integrates itself again as an error active node into the network.
Overload Frame conditions
A forth frame format is specified: the Overload Frame. Originally introduced to gain more time for processing the received data, today no CAN controller sends them actively. All CAN controllers are fast enough to store the received data. Nevertheless, the CAN protocols specify some conditions where an Overload Frame needs to be transmitted. It has the same structure and format as an active Error Flag. However, it doesn’t cause an increase of the error counters or an automatic retransmission of the message, because the message is already regarded as correctly received. Overload frames are sent if the first or second bit of the IMF is dominant. Another overload condition is the detection of a dominant bit-level in the 7th bit of the EOF (end of frame) by a receiving node. A transmitting node interprets a dominant bit at the last bit of the EOF as an error condition and retransmits it. Because the receiving nodes have already accepted the message as correct with the 6th bit of the EOF, they receive it twice. This is why in CAN networks no relative data should be exchanged. This includes delta counts, toggle bits, etc. If you want to transmit relative data, you have to make them absolute, for example by means of a message counter.