CAN-FD Migration: Where Backward Compatibility Actually Breaks

CAN-FD gets pitched as backward compatible with classic CAN, and at the physical layer, that's mostly true, a CAN-FD controller can transmit and receive classic frames without issue. The problem isn't the physical layer. It's everything downstream of it, on a network where classic and CAN-FD nodes have to coexist during a migration that rarely happens all at once.

Where "Backward Compatible" Stops Being True

A classic CAN controller cannot parse a CAN-FD frame. Not "parses it incorrectly", cannot parse it at all. If a CAN-FD node on a shared bus transmits an FD frame with the bit-rate switch (BRS) flag set, every classic-only node on that bus sees a frame that violates its expected format and raises a form error. Enough form errors and a classic node enters bus-off, taking itself off the network as a protection mechanism that was designed for a different failure scenario entirely.

This is the failure mode that doesn't show up in a two-node bench test. It shows up on a real vehicle or machine network with a dozen ECUs, some of which are years old and were never going to be replaced as part of the CAN-FD upgrade. The bench test passes. The field network doesn't.

The Three Places This Actually Bites

Data length code mismatch. Classic CAN caps payload at 8 bytes. CAN-FD supports up to 64. A gateway or bridge device that receives a 64-byte CAN-FD frame and needs to relay meaningful data onto a classic segment has to make a decision about what to do with the other 56 bytes, truncate, multi-frame, or drop. Most off-the-shelf gateway firmware doesn't make this decision correctly by default; it has to be configured deliberately for the specific PGN or message set in use.

Bit-rate switching on a bus that isn't tuned for it. CAN-FD's BRS feature switches to a faster bit rate for the data phase of a frame. That faster bit rate has tighter tolerances for bus length, termination, and node loading than classic CAN's already-tight budget. A bus segment that was marginal but functional at classic CAN speeds can start showing intermittent errors the moment BRS is enabled, even though nothing else on the network changed. This is a signal-integrity problem wearing a protocol-migration costume, and it gets diagnosed as a software bug more often than it should.

Silent gateways. The most dangerous version of this failure isn't a hard bus-off, it's a gateway that silently drops CAN-FD frames it can't translate, with no error surfaced anywhere. The network looks healthy. The classic nodes report no errors. But whatever data was riding on the dropped frames, a sensor reading, a status flag, a diagnostic trouble code, simply never arrives, and nothing in the system says why.

What an Actual Migration Plan Looks Like

The nodes that have to coexist during the transition period need to be mapped explicitly, which ECUs are staying classic CAN, which are moving to CAN-FD, and which are gateway or bridge points between the two. Every message that crosses that boundary needs its DLC and bit-rate handling defined, not assumed. And the physical bus, termination, stub lengths, node loading, needs to be re-validated against CAN-FD's tighter tolerances even on segments where nothing else is changing.

None of this is exotic engineering. It's the kind of protocol-level diagnostic work that catches a bus-off before it happens in the field rather than after a customer reports intermittent equipment faults that don't reproduce on the bench. The MicroCore Wireless CAN Bridge was built with exactly this kind of mixed-network reality in mind, CAN-FD native, with automatic fallback to classic CAN at 250/500 kbps, so a diagnostic tool doesn't become another point of protocol mismatch on a network that's already mid-migration.

If a CAN-FD rollout is showing intermittent faults that don't reproduce consistently, the bus-off logs and DLC handling at the gateway are usually where the actual answer is, not the application layer where the symptom shows up.

MicroCore Systems, Auckland, NZ. Contact: jonathan@microcoresystems.co.nz