CAN-FD Overview

CAN is the most widely used automotive protocol. Learn here about the variant CAN-FD (CAN Flexible Data-Rate)

It's a fact. CAN is the most popular automotive protocol. It's one of the cheapest options, provides very baud rates and is reliable in the noisy mess that is a vehicle. Even though other protocols give CAN a run for its money, such as LIN (you can learn about it in What is LIN (opens in a new tab)), by being cheaper and good enough if your application does not require a huge message throughput, and FlexRay (you can explore it further in What is FlexRay (opens in a new tab)), which is more expensive but faster.

When we overviewed CAN, in the article CAN Protocol Overview (opens in a new tab), we have already explored some limitations of CAN, such as the limited baud rate, of 1Mbps, and the inability to communicate data in a predictive manner, as it only supports event-based communication. Today, we'll cover two variants of CAN, CAN-FD (CAN Flexible Data-rate) and TTCAN (Time-Triggered CAN), which mitigate these two different issues and add a bit more to the value of this already pretty capable protocol. Today, we'll take a look at CAN-FD.

With the number of functionalities in a vehicle ever-increasing, it is normal to see CAN starting to struggle with high bus loads. The baud-rate (1Mbps) and data frame length (8 bytes) are starting to pose a limitation on the communication for many different vehicles. To delay the inevitable passing of CAN into history, CAN-FD was born. Its main benefits are:

• Increased Data Length - CAN-FD supports a frame length of 64 bytes, as opposed to the 8 bytes of CAN, increasing the efficiency of the protocol

• Faster Baud Rate - CAN-FD works with two different baud rates, 1 Mbps in the arbitration phase (as fast as CAN, in this case) and up to 5 Mbps while transmitting data, which falls short of the 12-15 promised in theory. The increased baud-rate also mitigates the possible delayes we would have caused by increasing the data length, while the slower arbitration phase is to keep the wire lengths manageable and allow for all nodes to react in time to the CAN frames

• More Reliable - By using an improved CRC and protecting the stuff-bit counter, CAN-FD reduces the chance of undetected communication errors, which is ever more vital

• Interoperability - CAN-FD and CAN ECUs can communicate, to some degree at least. Which means the OEMs are not required to drastically transition into CAN-FD all the vehicle ECUs, as the protocols are compatible

Now, let's turn our heads into the CAN-FD frames. There are a few new fields added, when comparing it with regular CAN, but nothing too serious that our extra baud-rate in the data stage cannot compensate for. Below, we can find a comparison between CAN and CAN-FD's messages, with hidden stuff bits for better comprehension:

CAN vs CAN-FD frames

The parameters, one by one:

• SOF (Start Of Frame) - Nothing new, the bit that signals the start of a transmission
• CAN-ID (CAN Identifier) - The identifier of a CAN message, which can also be extended (29 bits)
• RRS (Remote Request Substitution) - Replaces the RTR (Remote Transmission Request), which was used identify remote frames. Since remote frames are not supported in CAN-FD, RRS is always 0 (dominant)
• IDE (Identifier Extension) - Same as in CAN, used to specify if an identifier is 11 (0) or 29 bits (1)
• FDF (FD Frame) - denotes a CAN-FD frame, and is always recessive (1). Replaces the r0 (Reserved) bit (always dominant, 0) in classic CAN. Used to distinguish between classic CAN frames and CAN-FD frames. From this point forward, nodes incapable of CAN-FD will produce an error frame
• Res (Reserved) - Replaces r0. For now, it's dominant (0), but it might be used in the future to denote a new protocol, such as FDF does
• BRS (Bit Rate Switch) - Specifies if the data is sent at the arbitration rate (0) or at a higher bit rate (1)
• ESI (Error Status Indicator) - Indicates if there is an error (dominant, 0) or not (recessive, 1)
• DLC (Data Length Code) - such as in classic CAN, these four bits determine the message length, but there is a difference: in classic CAN, from 8 to 15, the size of the message is always 8 bytes, the maximum for the protocol, but in CAN-FD, these values can represent 12, 16, 20, 24, 32, 48 or 64, respectively
• Data - This one is self-explanatory. It's where your data goes
• SBC (Stuff Bit Count) - Consists of 3 bits and plus a parity bit, and specifies the modulo of 8 for number of stuff bits in the data, through a gray-coded value
• CRC (Cyclic Redundancy Check) - In classic CAN, the CRC was 15 bits and contained from 0 to 3 stuff bits. In CAN-FD, it can be of 17 bits (for up to 16 bytes of data) or 21 (from 20 to 64 bytes), and it always contains four stuff bits
• CRC Deliminter - Signals the end of the CRC
• ACK (Acknowledge) - Delimits the end of the data phase of CAN-FD
• ACK Delimiter - Signals the end of the ACK
• EOF (End Of Frame) - 7 recessive bits to delimit the end of a CAN-FD frame, just like in regular CAN
• IFS (Inter-Frame Spacing) - 3 recessive bits of leeway to prepare for the next frame

Lastly, let's discuss in which circumstances the CAN and CAN-FD protocols and nodes can coexist: either you have an entirely capable CAN-FD system, which allows you to mix both protocols, or CAN-FD nodes can switch from classic CAN to avoid error frames from the classic CAN nodes. Some classic CAN nodes can also be switched offf in certain circumstances to avoid errors and allow for a full CAN-FD capable system during certain periods.

Alright, now that you are a CAN-FD master, we hope you stick around for when we cover CAN-TT. See you next time!