CAN FD Protocol Tutorial

In this tutorial the Kvaser Technical Team will outline general CAN FD physical and datalink properties at a level targeted for test engineers. This document is designed to give the test engineer knowledge required to understand CAN FD at the bit and frame level, and to recognize the properties of CAN FD when displayed in a digital waveform or by an oscilloscope trace. For the systems engineer and the physical layer designer, there will be additional tutorials published by the Kvaser Technical Team at a future date.

CAN is short for ‘Controller Area Network’, and CAN FD is short for CAN with Flexible Data rate. Controller area network is an electronic communication bus defined by the ISO 11898 standards. In 2015 these standards were updated to include CAN FD as an addition to the previous revision, and the new reference number ISO 11898-1:2015(E) was assigned. The standard is written to make the information unambiguous, which unfortunately makes it hard to read because there are no extended descriptions or examples. The information in this tutorial is less formal, and designed to be easier to understand.

Collectively, this system is referred to as a CAN network, with Classical CAN and CAN FD as different Frame Formats supported by the standard.

Figure 1

Figure 4 shows the same trace as Figure 3, but with the bit measurement now around a data bit transmitted at the data bit rate. The result of this measurement is 249.9 ns. Rounding this off to 250 ns gives us a data bit rate of 4 MHz. It is interesting to note the gray indicators just above Data – 02 and Data – 03 in the middle right side on Figure 4, showing the location of stuff bits. See Bit Stuffing in the CAN Bus Protocol Tutorial for a full explanation of Bit Stuffing.

You might be asking yourself “How can you just turn up the bit rate in CAN FD and not introduce problems?”, or maybe “If you can turn up the bit rate in the Data phase, why don’t you just turn up the bit rate for the whole CAN frame?”. These are the logical questions to ask when presented with this information. The timing restrictions associated with the Arbitration phase of the CAN FD frame are different and more restrictive than those associated with the Data phase. This is because during arbitration there could be multiple devices transmitting on the network. It is only during Arbitration, and the Acknowledge (ACK) bit, that multiple physical devices can transmit simultaneously. It is this simultaneous transmission, possibly from devices at different ends of the network, that limits the nominal bit rate to the lower value of the arbitration phase. After arbitration is finished, only one device is still transmitting, and a higher data bit rate can be used. After the data and the Cyclic Redundancy Check (CRC) have been sent, the transmitter will switch back to the nominal bit rate, and the ACK bit will follow. It should be noted that the ACK-bit is actively transmitted by all units except the sender of the CAN-frame. This causes the same physical signal complexity as during the arbitration phase, which demands the use of the Nominal bitrate.

In CAN FD, the bitrate switch is in the sample point, and this switch must be done concurrently in all installed units (at the sample point in the nominal bit). This demands that all installed units have the same location of the sample point in the configuration of the nominal bitrate of the CAN FD frame. In Classical CAN, a system would survive sample point variation up to 20%. The problem is that 20% phase shift in the nominal CAN-bit of CAN FD will be 40% in the data-bit for a data bitrate that is only twice the nominal bitrate. For this reason, it is necessary to secure that all installed units have a common setting of the sample point in the nominal bitrate before the bitrate switch is used. Similar problems exist when switching from data bitrate to nominal bitrate, but in this case the phase shift is scaled down, and is therefore less problematic.

It is important to stress the significance of bit timing register configurations because the most common network problems are a result of mistakes made in configuring these registers. If you are using CAN FD in specific applications that are well documented, you will find that the nominal and data bit rates are specified in the standard. Other things that are specified for each phase of the CAN FD frame are the Synchronization Jump Width, Sample Point, Bit Rate Prescaler, as well as other timing and bit quanta parameters. This takes much of the complexity out of configuring your controller, simply because you must follow the standard. If one of these parameters differ from other nodes in the network, such as the Sample Point, you will get bit errors. 

When CAN was first introduced by Bosch in 1986 it was introduced with an eleven-bit identifier. At the time we referred to this as Standard CAN. A few years later a twenty-nine-bit identifier was introduced, and we called this Extended CAN. (see Standard vs. Extended CAN in CAN Messages section of CAN Bus Protocol Tutorial)

When CAN FD was incorporated into the ISO 11898 standard in 2015, two new frame formats were introduced, and the common way of referring to different frame formats was changed. Four new acronyms came into existence and started to be used by other CAN related standardization bodies as well. These acronyms are listed and defined here:

CBFF – Classical Base Frame Format: Original CAN with an 11-bit ID and 0 to 8 bytes of data.

CEFF – Classical Extended Frame Format: Original CAN with a 29-bit ID and 0 to 8 bytes of data.

FBFF – FD Base Frame Format: CAN FD with an 11-bit ID and up to 64 bytes of data.

FEFF – FD Extended Frame Format: CAN FD with a 29-bit ID and up to 64 bytes of data.

From this list it is easy to figure out that CAN FD can use either the eleven-bit identifier or the twenty-nine-bit identifiers. As with classical CAN, the identifier can be used to identify the data frame, or it can be used for some other purpose. This is dependent on the high-level protocol and is not defined in ISO 11898. Regardless of what the identifier is used for by the high-level protocols, it will always be used for arbitration because of how bit-wise arbitration works, as defined in ISO 11898 (see Bus Arbitration and Message Priority in CAN Bus Protocol Tutorial).

Figure 5

Substitute Remote Request (SRR)
This bit is only defined for Extended frames (IDE=1) and has a different use in the Base frame when IDE=0. For the 29-bits frame formats CEFF and FEFF where IDE=1, this bit substitutes the RTR-bit in CBFF and the RRS-bit in the FBFF. This bit is always sent recessive (SRR=1) for both frame formats. CAN FD receivers will accept SRR=0 without triggering a form error.

IDentifier Extension (IDE)
Unlike the bits I have described above, the IDE bit is always called the same thing, and it is always transmitted in the same time slot. For both the CBFF and FBFF, the IDE bit is dominant. That means for any Base Frame Format, that is any frames with an eleven-bit ID, IDE is dominant. For both CEFF and FEFF the IDE bit is recessive. That means for any Extended Frame Format, that is any frame with a twenty-nine-bit ID, IDE is recessive.

Remote Request Substitution (RRS)
Both CBFF and CEFF support RTR (Remote Transmission Request) which is indicated by a recessive bit (RTR=1) after the last ID bit. When an ordinary data frame is sent, this bit will be sent as dominant (RTR=0). In CAN FD remote request is not supported, and all CAN FD frames are data frames, which for Classical frames are indicated by dominant (RTR=0) bit. To indicate the different use in the CAN FD frames, this bit is named Remote Request Substitution (RRS). The RRS-bit is always sent dominant (RRS=0) because a CAN FD frame is always a data frame. CAN FD receivers will accept RRS as recessive (RRS=1) without triggering a form error. 

FD Format indicator (FDF)
This is the bit that distinguishes between classical CAN and CAN FD frames. It is dominant in the classical CAN frame formats (CBFF and CEFF), and recessive in the CAN FD frame formats (FBFF and FEFF). The FDF bit is not always transmitted in the same time slot. In the Base frame formats (CBFF and FBFF) the FDF bit is transmitted in the control field just after the IDE bit. Because the arbitration field is extended in frames with 29-bit identifiers (CEFF and FEFF), the FDF bit is transmitted after the RTR or RRS bits respectively in extended frame formats. This keeps it in the control field, so it is never included in arbitration.

Reserved bit in FD Frames (res)
This bit is only present in CAN FD frames and is always transmitted as dominant. It is reserved for future use and will most likely be used in CAN XL (the subject of a later protocol tutorial). Since it is transmitted as part of the control field it is not used in arbitration. It is interesting to note that it is called the r0 bit only in classical extended frames (CEFF), but still transmitted in the same state as dominant. The reason for the naming differences, and really for the existence of this bit, is for backward compatibility with previous versions of ISO 11898.

Bit Rate Switch (BRS)
This is a bit that is completely new to CAN FD, and did not exist in classical CAN. One of the big advantages of CAN FD is that the bit rate can be increased up to 8 Mbps after the arbitration field is transmitted. BRS is part of the control field, always transmitted just after the res bit. It indicates whether the bit rate is going to stay the same or switch up to a faster rate. The arbitration field is always transmitted at the nominal bit rate, and if BRS is recessive the bit rate will switch up to a higher data bit rate at the sample point of the BRS bit. So BRS is unique; it is the only bit whose state determines a timing shift at its own sample point. If BRS is sampled as recessive the bit rate will switch to the data bit rate, and sample points will have to switch accordingly. If BRS is sampled as dominant, the bit rate will remain the same for the rest of the CAN FD frame. Figure 2 is a representation of the control field that clearly shows the location of the sample point of BRS and the resulting change in bit timing from an active BRS.

Error State Indicator (ESI)
This is also a new bit only used in CAN FD. The ESI bit is used by a CAN FD node to indicate that it is in an error active state. By transmitting ESI as dominant, a node is indicating that it is in the error active state, and by transmitting it as recessive the same node indicates an error passive state. ESI is always transmitted in the control field, just after BRS. This means it is the first bit to be transmitted at the data bit rate in all CAN FD frames with BRS enabled.

If you want to learn more about error states, please see CAN Error Handling in the CAN Bus Protocol Tutorial.

In most communication protocols there is a block of bits, usually transmitted after everything else in the frame, called the Cyclic Redundancy Check (CRC). The CRC is not unique to CAN or CAN FD, it is used in many digital communication protocols. There is plenty of good information out there on the concept of CRCs, including entire books written on the concept alone. Classical CAN uses a 15-bit CRC and doesn’t include the stuff bits. CAN FD uses either a 17-bit CRC for data fields up to and including 16 bytes, or a 21-bit CRC for data fields 20 bytes and over. CAN FD also includes the stuff bits in the CRC calculation, and adds a 3-bit stuff count to be transmitted at the beginning of the CRC. Because of the larger data phase available in CAN FD, these changes are required to give CAN FD comparable error detection capability to that of classical CAN.

The CRC Delimiter is transmitted just after the last bit in the CRC sequence. When a CAN FD node reaches the sample point of the CRC delimiter, it switches from the data bit rate back to the nominal bit rate. This change can be seen in Figure 3, where the recessive CRC delimiter is a little longer than the data bits, and the dominant Acknowledge bit is displayed at the nominal bit rate.

The Acknowledge (ACK) bit is shown furthest to the right in Figure 5. It’s shown as recessive, although if you look at Figure 3 you see it as the last dominant bit in the frame. It is shown as recessive in Figure 5 because it is transmitted as recessive by the node that has transmitted the frame. It is the other nodes, all receivers on the network, that drive the ACK bit to dominant, just like in classical CAN. It only takes one node to drive the bus dominant, so what the ACK bit tells the transmitting node as it finishes transmitting a frame, is that at least one receiver has confirmed reception of the frame.