CAN FD On A Legacy CAN Bus Network Is Not A Good Idea Due To Compatibility Issues

My book, A Comprehensible Guide to Controller Area Network, was initially published in 2005, and while the technology behind the "Classical" CAN (a tag used by CAN-In-Automation) has not changed, the growing market acceptance of CAN FD (Flexible Data Rate) made me think about working on a second edition. I am aware that CAN FD was already released some seven years ago, but I also consider market acceptance before engaging into a possible hype. It is my experience that any new CAN Bus extensions and "improvements" are quickly praised and adopted in Germany, the origin of the CAN Bus technology. In contrast, the North-American market reacts with less enthusiasm. After all, the demand for faster CAN Bus transmission came from German car manufacturers.

On a side note, CAN-in-Automation (CiA) announced its intention to launch yet another flavor of the CAN Bus technology, namely CAN XL, which supports an extra-large (XL) payload of up to 2048 bytes.

Coming back to writing about CAN FD, during my research, I found a blog post by IXXAT, a subsidiary of HMS Networks, addressing CAN vs. CAN FD Compatibility (the post has now been removed). The compatibility issue occurs when using CAN FD on a legacy CAN Bus network, and this is not a matter of "if" but "when."

In short, Classical CAN and CAN FD data frames are very similar, the primary difference being that, during the data transmission phase, the FD frame will accelerate the data rate. Since a CAN FD data frame starts off looking like a valid CAN Bus frame, it is recognized by Classical CAN controllers as a Classical CAN data frame. However, during data transmission at a higher baud rate, the Classical CAN controller will not detect any stuffing bits and thus reject the frame by sending out an error frame.

There are two scenarios where the undesired outcome can be predicted: A single CAN FD node in a legacy CAN Bus network will eventually go into "Bus Off" mode after the rest of the bus reported errors. A single Classical CAN node in a CAN FD network will go into "Bus Off" mode after reporting too many errors.

Things become somewhat unpredictable in a mixed network, i.e., several Classical CAN and CAN FD nodes. However, the outcome will be the same, because there will be nodes transitioning into "Bus Off" mode. It's just not clear which nodes will do so.

As the blog entry states, the main conclusion is that using CAN FD on a legacy CAN bus is not a good idea and will almost certainly not work.

Supplement August 7, 2019 - From my Twitter account:

Teensy 3.2 With CAN FD Breakout Board

This is a CAN-Bus FD breakout board with the Microchip MCP2517FD CAN FD controller and Teensy 3.2. It has an on-board 5 VDC regulator and reverse voltage protection.

The MCP2517FD is a cost-effective and small-footprint CAN FD controller that efficiently connects to a microcontroller over an SPI interface. Consequently, the CAN FD channel presents an extension to a microcontroller that is either lacking a CAN FD peripheral, or that doesn’t have sufficient CAN FD channels.

The MCP2517FD supports both, CAN Bus data frames in the Classical format (CAN2.0 A/B) and CAN Flexible Data Rate (CAN FD) format.

More Information...