CAN-FD Bit Rate Switching - Vehicle Networks

Dual Bit-Rate Mechanism

CAN-FD Bit Rate Switch Timeline

  ←── Arbitration Phase ──→←─── Data Phase (BRS=1) ───→← Arb Phase →
  500 kbps                    2000 kbps                   500 kbps

  SOF  ID[10:0] RTR IDE FDF res BRS ESI DLC DATA[0-512b] CRC EOF
       ←── same 500 kbps ────────┤   ↑                        ↑
                                 │ Switch to data rate      Switch back
                                 │ (after BRS sample point) (before CRC delim)

  Key constraint: signal integrity during high-speed data phase
  At 5 Mbps: bit time = 200 ns; max segment stub length ≈ 30 cm
  (signal round-trip must complete in < 0.1 × bit time = 20 ns → 3 m/ns propagation)

Transceiver Requirements per Data Rate

Transceiver	Max Data Rate	Standard	Typical Application
TJA1044GT	2 Mbps	ISO 11898-2:2016	In-vehicle networks up to 2 Mbps data phase
TJA1462	5 Mbps	ISO 11898-2:2016	High-speed ADAS backbone up to 5 Mbps
TJA1463	5 Mbps + PN	ISO 11898-2:2016	Partial Networking capable, 5 Mbps
SIT1044	5 Mbps	ISO 11898-2:2016	Alternative to TJA1462
TJA1080	10 Mbps (FlexRay)	ISO 17458	Not CAN-FD — FlexRay only

⚠️ PCB Layout Critical at 5 Mbps

At 5 Mbps data phase, the bit time is only 200 ns. Signal reflections from stub mismatches longer than ~30 cm will arrive after the sample point and cause bit errors. PCB traces must be length-matched, terminated at 120 Ω at each bus end, and have controlled impedance (~120 Ω differential). Verify with a vector network analyser (VNA) or TDR before integration testing.

Separate Data-Phase Timing Registers

Ccan_fd_timing_config.c

/* STM32H7 CAN-FD (FDCAN) timing configuration */
#include "stm32h7xx_hal.h"

FDCAN_HandleTypeDef hfdcan1;

void CAN_FD_Init(void)
{
    hfdcan1.Instance = FDCAN1;
    hfdcan1.Init.ClockDivider = FDCAN_CLOCK_DIV1;

    /* Arbitration phase: 500 kbps at 80 MHz CAN clock */
    /* tq = 80 MHz / prescaler=8 = 10 MHz → 100 ns per tq */
    /* 20 tq × 100 ns = 2 µs bit time = 500 kbps */
    hfdcan1.Init.NominalPrescaler = 8;
    hfdcan1.Init.NominalSyncJumpWidth = 4;
    hfdcan1.Init.NominalTimeSeg1 = 13;  /* Prop+Ph1 = 13 tq */
    hfdcan1.Init.NominalTimeSeg2 = 2;   /* Ph2 = 2 tq */
    /* Sample point: (1+13)/(1+13+2) = 87.5% */

    /* Data phase: 2 Mbps at 80 MHz */
    /* tq = 80 MHz / prescaler=2 = 40 MHz → 25 ns per tq */
    /* 20 tq × 25 ns = 500 ns bit time = 2 Mbps */
    hfdcan1.Init.DataPrescaler = 2;
    hfdcan1.Init.DataSyncJumpWidth = 3;
    hfdcan1.Init.DataTimeSeg1 = 14;     /* Prop+Ph1 = 14 tq */
    hfdcan1.Init.DataTimeSeg2 = 5;      /* Ph2 = 5 tq */
    /* Sample point: (1+14)/(1+14+5) = 75% */

    hfdcan1.Init.FrameFormat = FDCAN_FRAME_FD_BRS;
    HAL_FDCAN_Init(&hfdcan1);
}

Oscilloscope Verification of BRS Transition

Measurement	Expected Result	If Wrong
Bus waveform before BRS bit	500 kbps bit times (2 µs)	Check arbitration-phase timing registers
Bus waveform after BRS bit	2 Mbps bit times (500 ns)	Check data-phase prescaler and segments
Bus waveform at CRC delimiter	Returns to 500 kbps	Check transceiver BRS pin connection
Eye diagram at data rate	Open eye; no reflections	Check PCB stub length and termination
TEC/REC after 1000 FD frames	Both = 0	Any non-zero → signal integrity or timing mismatch

Summary

Bit rate switching in CAN-FD requires separate timing register sets for arbitration and data phases, a transceiver rated for the target data rate (TJA1044 for 2 Mbps, TJA1462/TJA1463 for 5 Mbps), and careful PCB layout to avoid stub reflections at short bit times. Verify the BRS transition with an oscilloscope — the visible speed change in the waveform is unmistakable — and confirm zero TEC/REC after sustained traffic before declaring the physical layer validated.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.