CAN FD Migration: What Your Test Suite Needs to Change

CAN FD adoption is no longer optional for new automotive ECU platforms. If your ECU targets EV, ADAS, or any gateway-based architecture introduced after 2022, CAN FD is either already required or will be within the next design revision. Which means your test suite - written for CAN 2.0 - needs to evolve.

The good news: most of your existing test cases still work. The bad news: the ones that break will do so silently, producing wrong results rather than obvious errors. Here is exactly what changes and what to add.

What Stays the Same

Signal definitions, DBC content, and message IDs are unchanged between CAN 2.0 and CAN FD. A signal named EngineSpeed with the same start bit, length, factor, and offset in a CAN 2.0 DBC is the same signal in a CAN FD DBC. Your test cases that assert EngineSpeed values still work - provided the frame format is configured correctly.

The CAN Agent in TestBot handles both CAN 2.0 and CAN FD through the same agent. Switching a test case from CAN 2.0 to CAN FD requires one configuration change: enable the FD flag and set the data-phase bitrate. The test logic - send frame, receive response, assert signal value - is unchanged.

Change 1: Bitrate Configuration (Two Rates, Not One)

CAN 2.0 has one bitrate (typically 500 kbit/s). CAN FD has two: the arbitration phase bitrate (same as CAN 2.0, typically 500 kbit/s or 1 Mbit/s) and the data phase bitrate (higher, typically 2–8 Mbit/s). Both must be configured identically between the adapter and the ECU.

The test case change: update every CAN Agent configuration block that was set to a single bitrate to specify both arbitration and data phase bitrates. Test cases that run with mismatched bitrates will see all CAN FD frames as error frames - the CAN FD adapter will flag them, but the signal assertions will silently fail with timeout errors rather than obvious format errors.

Add an explicit bitrate validation test: send a known CAN FD frame at the configured data phase bitrate and assert the receive timestamp confirms the data phase bitrate by measuring the inter-bit time. This catches adapter configuration mismatches immediately rather than after a suite of timeout failures.

Change 2: DLC Encoding - Non-Linear Above 8 Bytes

CAN 2.0 DLC values map linearly: DLC 0 = 0 bytes, DLC 8 = 8 bytes. CAN FD extends this with a non-linear mapping for payloads above 8 bytes:

• DLC 9 = 12 bytes
• DLC 10 = 16 bytes
• DLC 11 = 20 bytes
• DLC 12 = 24 bytes
• DLC 13 = 32 bytes
• DLC 14 = 48 bytes
• DLC 15 = 64 bytes

Test cases that validate payload length by asserting DLC = number of bytes will produce wrong results for any CAN FD message with more than 8 bytes. Update payload length assertions to use the CAN FD DLC-to-byte-count mapping. Add explicit test cases that send CAN FD frames with DLC values of 9–15 and assert the byte count received matches the DLC mapping above.

Change 3: CRC Algorithm - 17-bit and 21-bit

CAN 2.0 uses a 15-bit CRC. CAN FD uses a 17-bit CRC for frames with 0–16 bytes of data and a 21-bit CRC for frames with 17–64 bytes. The adapter handles CRC computation automatically - you do not write CRC code - but test cases that inject error frames by flipping CRC bits need to account for the larger CRC field.

Add a CRC error injection test for CAN FD frames: inject a single-bit flip in the CRC field of a CAN FD frame and assert the receiving ECU generates an error frame and increments its error counter. If the error counter does not increment, the ECU's CRC validation is not active for CAN FD frames.

Change 4: Transceiver Delay Compensation

At high data-phase bitrates (5 Mbit/s and above), the signal propagation delay through the CAN FD transceiver and the bus becomes a significant fraction of the bit time. The transceiver delay compensation (TDC) parameter compensates for this. Misconfigured TDC causes intermittent bit errors at high data-phase bitrates that do not appear at lower bitrates.

Add a stress test: run a continuous CAN FD traffic sequence at the maximum configured data phase bitrate for 60 seconds and count error frames. A correctly configured TDC produces zero error frames. Misconfigured TDC produces intermittent error frames - typically less than 1% of frames, but enough to cause occasional frame loss at the application layer. This test catches TDC misconfiguration that functional tests never expose.

Change 5: Mixed-Network Coexistence

Many ECU networks include both CAN FD-capable nodes and legacy CAN 2.0 nodes during the migration period. CAN FD frames sent on a network with a CAN 2.0 node will cause the CAN 2.0 node to generate error frames - because it sees bits after the DLC field that do not conform to CAN 2.0 framing.

Test the mixed-network scenario explicitly: connect both a CAN 2.0 node (emulated by TestBot's CAN Agent in CAN 2.0 mode) and the CAN FD ECU to the same bus. Verify that CAN FD frames from the ECU do not cause the CAN 2.0 node to generate error frames. If they do, the ECU needs to either disable CAN FD for frames that legacy nodes subscribe to, or the bus topology needs to isolate CAN FD segments from CAN 2.0 segments.

The Net Change: One New Configuration, Five New Test Cases

Migrating an existing CAN 2.0 test suite to CAN FD is not a rewrite - it is a configuration update plus five additional test cases that validate CAN FD-specific behaviour. The signal validation, timing, and application-layer test cases you already have continue to work. What you add is the layer of CAN FD-specific validation that your existing suite cannot see.