CAN with Flexible Data-Rate (CAN FD)#

Protocol Additions#

CAN FD (CAN with Flexible Data-Rate) is an upgrade of the CAN specification that allows larger data frames (up to 64 bytes of data per frame) and allows switching the bitrate to a higher value for the transmission of the data bytes.

CAN FD specifies a new meaning for the reserved bit r0 of the CAN 2.0 specification: r0 is now called FDF, and if it is recessive, the frame is now a CAN FD frame.

../../_images/CAN-FD-Frame-11-Bit-Identifier-FDF-Res_2.png

Fig. 37 Comparison between Classic CAN frame and CAN FD frame (https://www.csselectronics.com/pages/can-fd-flexible-data-rate-intro)#

Other fields added by CAN FD:

  • RRS: replaces RTR, it’s always dominant (0) because remote frames are not supported in CAN FD

  • BRS: if recessive (1), the data and CRC fields are sent with a higher bit rate (up to 12mbps). The bitrate is switched IMMEDIATELY after BRS is sampled (the BRS bit is shorter than other arbitration bits!)

  • ESI: if recessive (1), the transmitter of this frame was in “error passive” mode.

  • DLC: the DLC is still encoded in 4 bits like in a normal can, but sizes above 8 bytes are interpreted to different values based on a lookup table

  • RES: reserved bit for the next version of the protocol

  • CRC: the CRC field of CAN FD has been expanded from 15 bits to 17 or 21 depending on the size of the message. The CRC algorithm was also changed to include the stuff bits in the calculation. The CRC field is sent with fixed stuff bits every 4 bits.

ISO 11898-1:2015 vs. non-ISO Bosch CAN FD 1.0#

The original specification of CAN FD from 2012 [RobertBGmbHb] contained a bug with how the CRC was defined, making it capable of detecting *LESS errors than the classic CAN protocol. A revision called “ISO 11898-1:2015” redefines the CRC calculation, but sadly it is not compatible with the non-ISO Bosch CAN FD 1.0 specification from 2012. Each CAN bus can not contain a mix of “non-ISO Bosch CAN FD 1.0” and updated “ISO 11898-1:2015” nodes.

The sampling point issue#

In the original CAN protocol, only the bitrate must be the same across all nodes in a bus. In CAN FD, arbitration bitrate and data bitrate must have the same values across all the nodes, but the sampling point is also important!

../../_images/rtaImage.jpeg

Fig. 38 Incorrect/Unexpected Behaviour or Slow CAN Frames When Using NI-XNET in CAN FD & BRS (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7mDSAS&l=de-DE)#

Using CAN FD in SocketCAN#

sudo ip link set can0 down  # Bring down the interface, to disable non-FD CAN if it was enabled previously

sudo ip link set can0 up type can \
    fd on \
    bitrate 500000 \
    dbitrate 5000000 \
    sample-point 0.875
    # 'bitrate' is the arbitration bitrate, 'dbitrate' is the data bitrate
    # 'sample-point' must also be identical on all nodes on the bus

Now to send some CAN FD frames with cansend, just use 2 # instead of 1. The first nibble indicates the BRS, ESI, and RES flags.

cansend can0 111##0  # Send an empty CAN FD message with identifier 0x111
cansend can0 222##0deadbeef  # Send a 4 bytes CAN FD message with identifier 0x222, without switching bitrate
cansend can0 333##0deadbeefdeadbeefdeadbeefdeadbeef  # Send a 16 bytes CAN FD message without switching bitrate
cansend can0 444##1deadbeefdeadbeefdeadbeefdeadbeef  # Send a 16 bytes CAN FD message with an higher bitrate for the data
../../_images/canfd-frame.png

Fig. 39 A CAN FD frame as seen on an oscilloscope#

../../_images/bitrate-switch.png

Fig. 40 Bitrate switch, showing the duration of the BRS bit compared to the other bits with a sample point of 0.875#