CAN FD – which stands for CAN with Flexibele Data-rate – is a new variant of the CAN protocol designed for applications requiring a higher data rate. This higher data rate is achieved, firstly, through a higher bus speed – but only during the data phase – which is up to 12 times faster than CAN Classic. Secondly, by transmitting many more data bytes – up to a maximum of 64 bytes in a single message, 8 times as many as with CAN Classic.
The start and end phases are arbitration phases because the value of bits is determined arbitrarily during these phases, as is the case in CAN Classic. This applies, for example, to the Identifier, the RTR bit and, at the end, the Acknowledgement. As other CAN nodes must respond within the bit time, the speed cannot be increased here.
CAN FD versus CAN
CAN FD protocol controllers are 100% compatible with CAN Classic – 2.0 (A/B) – and are therefore also capable of participating in standard CAN Classic communication. This offers the possibility of gradually migrating CAN nodes from CAN Classic to CAN FD. However, the two variants cannot simply be used interchangeably; see the section on Mixed Mode below.
Like CAN Classic, CAN FD supports the standard 11-bit and extended 29-bit identifiers.
CAN FD uses the (first) reserved bit in a CAN frame. In a CAN Classic frame, this reserved bit is transmitted as ‘dominant’ (=0). In a CAN FD frame, however, this bit is ‘recessive’ (=1) to indicate that the frame is being transmitted in the CAN FD format. A CAN FD controller is capable of decoding both formats.
CAN FD differences
There are two key differences between CAN FD and CAN Classic frames.
- Firstly, CAN FD frames offer the possibility of transmitting more than 8 data bytes;
- Furthermore, CAN FD frames have the option to switch to a different, and much higher, bit rate during the data phase, i.e. after the arbitration phase in the CAN frame has been completed.
CAN FD requires two sets of bit timing configuration registers for this purpose: the first set for the bit timing during the arbitration phase and the second set for the bit timing for the subsequent data phase. The timing for the bit arbitration phase has the same constraints as in CAN Classic; the bit timing for the data phase is selected based on the characteristics of the chosen transceiver and within the capabilities of CAN FD. The bit timing of both sets may, of course, also be identical.
There is a reason for this dual speed. During the arbitration phase of a CAN message, both at the start and at the end, other nodes must respond within one bit time. Due to the delay in the physical layer and the bus length, the speed cannot be increased under standard conditions.
Standard CAN transceivers – known as CAN High Speed – can also be used for CAN FD. Specialised CAN FD transceivers, designed for higher speeds, are optional. These are known as CAN SIC, an abbreviation for Signal Improvement Capability. CAN FD protocol controllers may be equipped with additional interface signals to switch – during the phase with a higher bit rate – to a CAN SIC transceiver. Such transceivers can utilise an alternative signal encoding during the higher bit-rate phase and are not limited to the standard CAN NRZ encoding.
The cost of CAN FD, in volume terms, is no higher than that of CAN Classic.
CAN FD and CAN Classic in Mixed Mode
The use of both CAN FD and CAN Classic has already been briefly mentioned. In such a mixed environment, CAN Classic controllers are used alongside CAN FD controllers. CAN FD controllers also support CAN Classic frames. However, original CAN Classic controllers – original CAN 2.0 – cannot operate on a bus over which CAN FD frames are also transmitted. As soon as the first CAN FD bit appears in a CAN message, such a CAN Classic controller will interpret this as an error and send an error message.
Newer CAN Classic controllers are CAN FD-tolerant. Whilst they cannot themselves receive or transmit CAN FD messages, they do accept CAN FD messages passing over the bus. A CAN network can therefore only achieve the higher data rate if all nodes are equipped with the CAN FD protocol or are CAN FD-tolerant.
By modifying the software in CAN Classic nodes, CAN FD is possible – albeit indirectly and with certain limitations. Before a CAN FD message is sent, the software in CAN Classic nodes switches the controller to Tx-passive or standby mode. This prevents it from generating an error on the bus and ensures that CAN FD traffic is not disrupted.
It should be clear that such a switch cannot be made continuously or on the fly. Consequently, CAN FD can only be used in specific operating modes, such as software downloads during end-of-line programming or maintenance, whilst the other (CAN Classic) controllers that do not support CAN FD are kept in standby mode. In this way, the benefits of CAN FD can still be utilised (at least) partially.
Forward compatibility
The major problem with CAN Classic is therefore that it lacks the capability to accommodate future CAN protocols. If a CAN Classic node does not (fully) recognise a protocol, it will generate an error that consequently blocks the use of new protocols.
In CAN FD, this has been resolved through the implementation of a Protocol Exception State. This state is triggered when a new CAN protocol places the CAN FD node into the Protocol Exception State. In that case, the CAN FD node will ignore this unknown message, but will certainly not send an error message. It will resume participating in CAN traffic with the next frame.
CAN XL makes use of this. This allows the new CAN XL messages to be transmitted over a mixed CAN FD / CAN XL network, without the need to modify the CAN FD nodes.
