CAN FD vs CAN 2.0: dual bitrates, 64-byte payloads, new CRC algorithm. What your test suite must cover and how to automate it - one adapter, no extra hardware.

CAN FD testing is the validation of Controller Area Network Flexible Data-rate communication - verifying that ECUs correctly transmit and receive CAN FD frames with both classical and data-phase bitrates, correct payload sizes up to 64 bytes, and correct bit rate switching behaviour.
CAN FD (ISO 11898-1:2015) extends classical CAN 2.0 in two ways: the data phase can run at a higher bitrate (typically 2–8 Mbit/s vs 500 kbit/s for the arbitration phase), and the payload can carry up to 64 bytes per frame (vs 8 bytes in CAN 2.0). These changes increase throughput for high-bandwidth ECUs - ADAS cameras, V2X modules, domain controllers - but introduce new failure modes that CAN 2.0 testing tools cannot catch.
What changes in CAN FD testing vs CAN 2.0: bitrate switching validation, extended payload encoding, DLC-to-byte-count mapping (CAN FD uses a non-linear DLC field), CRC algorithm differences, and transceiver delay compensation configuration.
Understanding these differences determines what your test suite must cover beyond classical CAN.
CAN FD uses a lower bitrate for arbitration (typically 500 kbit/s or 1 Mbit/s) and switches to a higher bitrate for the data phase (2–8 Mbit/s). Your test setup must validate correct bitrate switching and that the ECU's transceiver delay compensation is configured correctly for the data phase bitrate.
CAN FD extends the payload from 8 bytes (CAN 2.0) to up to 64 bytes. The DLC field uses a non-linear encoding: DLC 9–15 map to 12, 16, 20, 24, 32, 48, and 64 bytes respectively. Test cases must cover all valid DLC values and verify correct payload size handling.
CAN FD uses a 17-bit or 21-bit CRC (vs 15-bit in CAN 2.0) for improved error detection over longer data phases. Automated testing must verify that the ECU rejects frames with invalid CRCs and that CRC stuffing rules are implemented correctly.
CAN FD-capable transceivers and adapters are backward compatible with classical CAN frames. A CAN FD adapter can send and receive both CAN 2.0 and CAN FD frames on the same network. TestBot's CAN Adapter is CAN FD capable - no separate hardware purchase for CAN FD testing.
TestBot's CAN / CAN FD Agent supports both CAN 2.0 and CAN FD on the same adapter. CAN FD mode is enabled by configuration - no additional hardware or licence required.
| Scenario | TestBot Blocks Used | Validated Outcome |
|---|---|---|
| CAN FD Frame Transmission at 2 Mbit/s Data Phase | CAN FD Send Frame (data phase 2Mbit/s) + CAN FD Receive + DLC Assert | Frame received with correct payload size, DLC correctly decoded |
| Maximum Payload (64 bytes) Validation | CAN FD Send Frame (DLC=15, 64 bytes) + Payload Assert | Full 64-byte payload transmitted and received without CRC error |
| Mixed CAN 2.0 / CAN FD Network | CAN 2.0 Send + CAN FD Send + CAN Monitor | Both frame types coexist on bus, no error frames, all signals decoded correctly |
| Bitrate Switching Validation | CAN FD Send + Bitrate Monitor | Arbitration phase at 500 kbit/s, data phase at 5 Mbit/s, switching point correct |
| CAN FD CRC Error Injection | CAN FD Fault Inject (CRC) + Error Frame Monitor | ECU rejects CRC-invalid frame, error frame counted, no bus-off triggered |

CAN FD (Flexible Data-rate) extends classical CAN with two-phase bitrate operation and up to 64 bytes of payload per frame. It needs different testing because: (1) bitrate switching must be validated, (2) DLC encoding is non-linear and must be tested for all payload sizes, (3) a different CRC algorithm is used, and (4) transceiver delay compensation must be configured correctly for the data phase bitrate.

The foundational CAN 2.0 guide - frame validation, DBC testing, fault injection.

ISO 14229 diagnostic services - session management, DID, fault memory, flash programming.

ISO 13400 - CAN FD is being replaced by Ethernet/DoIP on EV and ADAS platforms.
One CAN Adapter covers both CAN 2.0 and CAN FD. 14-day free trial.