STM32G4 CAN-FD实战：FDCAN配置与高速通讯要点解析

简介：面向嵌入式开发者的 STM32G474 CANFD 通信实例资源，基于 FDCAN 控制器实现高速收发，覆盖 Bus-Off 错误处理、仲裁段 500K 与采样点 0.8、数据段 2M 与采样点 0.75 等关键参数配置，可帮助快速搭建 CANFD 工程并规避常见问题。压缩包共 1161 个文件、19.01MB，主体为 C/H 源码，辅以汇编文件、文本说明、IAR/Keil 工程文件与 STM32CubeMX 初始化文件，库文件和链接脚本一应俱全，目录清晰，适合直接导入工程或按模块研读。已有 2571 人学习，预览可见 DSP 数学库、HRTIM 驱动等模块，适用场景从外设控制到实时通信均有涉及。深入分析源码，可理解 FDCAN 初始化、报文滤波、中断及错误恢复流程，并借鉴多段波特率与采样点设计思路，提高高实时应用下通信的稳定性与可靠性。 拿到stm32g4_canfd.zip这个工程包的时候，我第一反应是这哥们儿终于对 G4 系列下手了。说实话，这些年玩 CAN-FD 的大多还守着 F4、H7 那几块老阵地，STM32G4 的 FDCAN 外设一直有点“养在深闺人未识”的意思。但只要你用过一次 G4 的 FDCAN，就很难再回去折腾软件模拟 CAN 或者外挂控制器那套方案了——这芯片的 FDCAN 模块属于正儿八经的 CiA 规范实现，加上内部集成的那颗高精度定时器，搞车载通讯、机器人关节控制、工业现场总线网关，那叫一个顺手。

这个工程包正是围绕 STM32G4 的 FDCAN 外设展开的，核心场景就是让开发者能快速跑通 CAN-FD 通讯：仲裁段保持 500kbps 经典速率，数据段直接飙到 2Mbps 甚至 5Mbps，一帧最多能塞 64 字节。说白了，它就是传统 CAN 2.0 的“涡轮增压版”——老协议还在用 8 字节小水管慢慢灌，CAN-FD 已经是一车皮一车皮地拉货了。

如果你正打算在 G4 上做 CAN-FD 通讯，或者想把老项目从 H7 往 G4 上迁移，又或者你单纯想知道 FDCAN 的配置坑到底有多少，那这个工程包值得你仔细拆一遍。接下来我把工程结构、配置参数、收发流程和踩过的坑从头到尾捋一遍，顺序和逻辑都是我实际调试时验证过的，你可以直接照着操作。

1. 项目整体设计与选型思路

1.1 为什么用 STM32G4 做 CAN-FD

先解决一个最实际的问题：市面上能跑 CAN-FD 的芯片一抓一大把，凭什么选 G4？我的理由有三个，任何一个都足够说服你。

第一，G4 系列的 FDCAN 外设不是“阉割版”，而是完整支持 ISO 11898-1:2015 标准的硬件控制器。它和 STM32H7 上那套 FDCAN 几乎同源，寄存器结构基本一致，也就是说你在 H7 上写的驱动代码，迁移到 G4 上只需要改改时钟配置，逻辑层几乎不用动。

第二，G4 自带 170MHz 主频的 Cortex-M4F 内核，跑 FDCAN 的协议栈绰绰有余。更重要的是，G4 的 FDCAN 时钟源可以选择从 PLL 输出直接拉，这就让数据段的位时序有了更细腻的调整空间——你可以配出 5Mbps 甚至更高的速率，对某些需要高吞吐的场合（比如电池管理系统的多节点数据聚合）非常实用。

第三，G4 内部集成了硬件过采样滤波、时间戳捕获和发送事件 FIFO，这些特性在工业现场做故障诊断时极其有价值。你可以在总线拥堵的时候精确记录每一帧的发送时刻，这在经典 CAN 时代是要靠外挂逻辑分析仪才能做到的事。

1.2 工程包内容与文件结构

解压stm32g4_canfd.zip之后，目录结构基本长这样：

• Core/Src/main.c：系统初始化、外设时钟配置、主循环逻辑
• Core/Src/fdcan.c：FDCAN 外设初始化、过滤器配置、收发函数封装
• Core/Src/stm32g4xx_it.c：中断服务函数，FDCAN 接收中断和错误中断处理
• Core/Inc/fdcan.h：FDCAN 相关的宏定义、全局变量声明、API 声明
• MDK-ARM或EWARM目录：编译工程文件

这种结构是标准的 CubeMX 生成风格，没有花里胡哨的嵌套。主循环里做的事情也简单粗暴：周期性地发送一帧 CAN-FD 数据，同时把接收到的数据原样打印到串口。你拿到手之后，改改波特率和数据内容就能直接上板子跑。

1.3 选型方案避坑说明

有同学会问：G4 的 FDCAN 和 G0/G1 的有什么不一样？这里要提醒一句，G0/G1 系列虽然也带 FDCAN，但它们的时钟系统比 G4 简化了不少，位时序的档位没那么多。如果你需要跑高速率（数据段 5Mbps），G4 的灵活性明显更好；如果只是低速巡检节点，G0 倒是可以省一颗晶振的钱。

另外，千万别把 G4 的 FDCAN 和 F3 系列那个老的 bxCAN 混为一谈。bxCAN 只支持经典 CAN 2.0，硬件上不认 CAN-FD 帧。你拿 CAN-FD 的报文去怼 bxCAN，它要么丢帧要么报错，根本不是“改个配置”就能解决的问题。所以，如果你的需求里明确写了“CAN-FD”，直接认准带 FDCAN 外设的型号，别走弯路。

2. 核心配置解析与实操要点

2.1 时钟树配置：FDCAN 的命脉

FDCAN 外设的时钟源选择是整个配置里最容易翻车的地方。打开 CubeMX 的 Clock Configuration 页面，你会看到 FDCAN 的时钟来源可以是 APB1 总线时钟，也可以是 PLL1Q 或 PLL2Q 的输出。

我强烈建议你把 FDCAN 的时钟直接从 PLL 拉，而不是用 APB1。原因很直接：APB1 的时钟频率往往带有分频系数，不够灵活。比如你的系统主频跑到 170MHz，APB1 分频到 85MHz，这时候 FDCAN 的时钟就是 85MHz。虽然也能工作，但你在计算位时序时会被这个 85MHz 绑住手脚，很多档位配不出来。

实际项目中，我常用的组合是这样的：系统主频 170MHz，PLL1Q 输出 85MHz，直接喂给 FDCAN。这样一来，仲裁段 500kbps、数据段 2Mbps 的典型配置，位时序参数都是整数，算起来特别舒服。

注意：CubeMX 里配置好时钟后，一定要去fdcan.c里确认hfdcan1.Initialize.ClockDivider这个字段。工程模板里默认可能是 1，也就是不分频。你要是拿 APB1 当时钟源，这里还得减半处理。

2.2 位时序计算：手动算一遍才算真的会

CAN-FD 的位时序和经典 CAN 思路一样，都是把每一位的时间切成若干时间量子（Time Quantum，Tq），然后由同步段、传播段、相位缓冲段组成。区别在于，CAN-FD 有仲裁段和数据段两套位时序，仲裁段的速率往往和数据段差好几倍。

就拿前面说的 85MHz 时钟、仲裁段 500kbps 来举例。位时间 = 85MHz / 500kbps = 170 Tq。如果采样点设置在 80%，那么同步段固定为 1 Tq，传播段加相位缓冲段1 加起来就是 135 Tq 左右，相位缓冲段2 则是剩余的 34 Tq。当然，实际配置时你不需要盯这么细，CubeMX 的 Bit Timing 页面能自动算，但你要能看懂这些数字是干什么的，不然出了问题只能瞎猜。

数据段 2Mbps 的位时间 = 85MHz / 2Mbps = 42.5 Tq，这时需要把Data Prescaler调大一点，把每个数据位的 Tq 控制在比较宽的范围。实际操作里我一般把数据段的位时间定在 20 Tq 上下，采样点同样选 80%，这样在恶劣的总线环境下也能保证比较高的抗干扰能力。

这些参数在 CubeMX 里配置完了之后，记得在代码初始化里核对一遍实际写入寄存器的值。CubeMX 有个毛病，有时候你修改了界面上的参数，但生成代码的时候没有完全同步到位。检查方式很简单，看FDCAN_InitTypeDef里NominalPrescaler、NominalTimeSeg1、NominalTimeSeg2、DataPrescaler、DataTimeSeg1、DataTimeSeg2这几个字段的实际数值，和你在界面上看到的是不是一致。

2.3 帧格式选择：经典帧、FD 帧还是 BRS

FDCAN 的帧格式有三种：经典 CAN 帧、FD 帧不带 BRS（Bit Rate Switch）、FD 帧带 BRS。从配置角度来说，最关键的就是FDCAN_FRAME_FD_BRS这个选项，它决定了一帧数据里是不是一半慢速一半快速。

选 BRS 的好处很明显：仲裁段的 500kbps 保证总线上的所有节点都能参与仲裁，等仲裁赢了之后，数据段立刻切到 2Mbps 甚至更高，把 64 字节的数据“嗖”地一下发完。这种“慢开车、快拉货”的策略是 CAN-FD 的核心价值，你用 CAN-FD 结果不选 BRS，那还不如老老实实发经典帧来得稳定。

但是有个坑必须提醒你：如果你的通讯对端是 CAN-FD 但不支持 BRS，或者对端是老的经典 CAN 节点，那么你发带 BRS 的帧过去，对端会直接报错。这种情况下，你需要动态地根据对端能力选择帧格式。G4 的 FDCAN 支持发送时逐帧指定格式，这个灵活度是很高的。

2.4 滤波器配置：别让垃圾帧打断你

FDCAN 的过滤器比经典 CAN 丰富的多。在fdcan.c里，你通常能看到FDCAN_FilterTypeDef结构体的配置，包括过滤器索引、ID 类型（标准帧还是扩展帧）、过滤模式（掩码模式还是列表模式）等。

我的习惯是配置成列表模式，把所有需要接收的 CAN-ID 一个个列出来，任何一个不匹配的帧都直接拒绝掉。这么做虽然配置代码稍长，但好处是接收中断不会被无关报文反复触发，CPU 占用率能压得很低。

一个容易忽略的地方是过滤器要作用到哪个 FIFO。G4 的 FDCAN 通常有两个接收 FIFO（FIFO0 和 FIFO1），你必须在初始化里指定过滤器关联到 FIFO0 还是 FIFO1，同时还要在FDCAN_Rx FIFO0 中断和FDCAN_Rx FIFO1 中断里只开对应的那一个，不然会收不到数据。

3. 实操过程与代码实现细节

3.1 从 CubeMX 到 Keil：完整配置流程

这部分我按实际操作的顺序来写，你可以一步步对着做：

1. 打开 CubeMX，新建 STM32G474RETx 工程。选 G474 是兼顾性价比和资源的常见选择。
2. 在 Pinout & Configuration 页面，搜索 FDCAN1，如下图方式配置。如果芯片同时有 FDCAN1 和 FDCAN2，而你只需要一个，可以先把另一个的引脚全保持默认。
3. 使能 FDCAN1 全局中断，NVIC Settings 里勾选 FDCAN1_IT0 和 FDCAN1_IT1 这两个中断线。注意，FDCAN 的中断向量不止一个，不同中断事件分属不同中断线，漏配到错误的 IT 线上会导致中断服务函数里拿不到事件标志。
4. 配置初始化参数，把前面算好的 NominalPrescaler、DataPrescaler 这些值填进去。框里可以填寄存器值，也可以填速率让 CubeMX 反推，反推有时候不准，填完记得打开计算器核验一遍。
5. 在 Clock Configuration 里把 FDCAN 的时钟源选成 PLL1Q，频率设成 85MHz。
6. 点击 Generate Code，生成工程，用 Keil 打开。

有人说，我用 STM32CubeIDE 不用 Keil，行不行？当然行，生成后的代码是同一个底层 HAL 库，IDE 区别只在编译调试环节，不影响这部分配置逻辑。

3.2 发送流程：按部就班的四步走

在main.c里，发送函数的核心逻辑是这样的：

FDCAN_TxHeaderTypeDef TxHeader; uint8_t TxData[64]; uint32_t TxMailbox; TxHeader.Identifier = 0x123; TxHeader.IdType = FDCAN_STANDARD_ID; TxHeader.TxFrameType = FDCAN_DATA_FRAME; TxHeader.DataLength = FDCAN_DLC_BYTES_16; TxHeader.FDFormat = FDCAN_FD_CAN; TxHeader.BitRateSwitch = FDCAN_BRS_ON; TxHeader.TxEventFifoControl = FDCAN_NO_TX_EVENTS; for (int i = 0; i < 16; i++) { TxData[i] = i; } HAL_FDCAN_AddTxMessage(&hfdcan1, &TxHeader, TxData, &TxMailbox);

这里面有四个关键点要留神：

第一，DataLength这个字段不是直接写字节数，而是要写成FDCAN_DLC_BYTES_16、FDCAN_DLC_BYTES_32、FDCAN_DLC_BYTES_64这样的宏。你直接填 16，HAL 库会报断言错误。这个坑我见过好几个人踩过。

第二，BitRateSwitch如果置为FDCAN_BRS_ON，对端必须支持 BRS，否则发送会失败。如果你不确定对端支持情况，先把这一项关掉，跑通基础通讯再加 BRS。

第三，HAL_FDCAN_AddTxMessage返回值一定要检查。如果返回HAL_BUSY，说明三个发送邮箱全满，数据没发出去。这时候你的业务层要做缓存或重试，而不是直接丢弃。

第四，发送完成后，如果你想确认报文确实送到了总线上，可以开启发送事件 FIFO，把TxEventFifoControl改成FDCAN_STORE_TX_EVENTS，然后查询事件 FIFO 里的时间戳。这个方法在调试多节点同步时非常好用。

3.3 接收流程：中断驱动的正确姿势

接收部分我建议用中断，而不是轮询。G4 的 FDCAN 接收中断配置好后，代码写起来非常清爽：

void HAL_FDCAN_RxFifo0Callback(FDCAN_HandleTypeDef *hfdcan, uint32_t RxFifo0ItFlags) { FDCAN_RxHeaderTypeDef RxHeader; uint8_t RxData[64]; HAL_FDCAN_GetRxMessage(hfdcan, FDCAN_RX_FIFO0, &RxHeader, RxData); // 处理接收到的数据 printf("Rx ID: 0x%lx, Len: %lu, Data: ", RxHeader.Identifier, RxHeader.DataLength >> 16); }

打开接收中断的操作是在初始化代码里加一句：

HAL_FDCAN_ActivateNotification(&hfdcan1, FDCAN_IT_RX_FIFO0_NEW_MESSAGE, 0);

注意调用时机，这句话必须在HAL_FDCAN_Start(&hfdcan1)之前执行，否则中断可能在你还没来得及启动外设的时候就触发了，或者干脆不会触发。

RxHeader.DataLength这个字段有讲究，它不是单纯的字节数，而是把 DLC 编码在 bit 16~19。也就是说，你需要右移 16 位才能得到实际的字节数，要判断具体是 8 字节、16 字节、32 字节还是 64 字节，可以用FDCAN_GET_BYTES_FROM_DLC(RxHeader.DataLength)这个宏。直接打印%d看到的数字会很奇怪，不是你不小心，是数据格式本来就是这样。

另外，G4 的接收 FIFO 溢出之后，新帧会直接丢弃，但溢出标志会置位。如果你发现接收偶尔丢帧，打开FDCAN_IT_RX_FIFO0_MESSAGE_LOST中断，在回调里记录一下溢出次数，这能帮你判断是总线负载太高还是接收端处理不过来。

3.4 回环模式：没有对端也能调

工程包里的fdcan.c默认配置的是正常模式。你拿到板子如果只有一块，没有 CAN-FD 分析仪，也没有对端节点，调试收发会变得比较尴尬。这时候可以临时把FDCAN_MODE改成回环模式：

hfdcan1.Initialize.FrameFormat = FDCAN_FRAME_FD_BRS; hfdcan1.Initialize.Mode = FDCAN_MODE_INTERNAL_LOOPBACK;

内部回环模式下，你发送的帧会被 FDCAN 控制器自己接收，不需要外部收发器参与。这个模式适合验证寄存器配置是否正确、DMA 搬运是否正常、中断是否能触发。等回环跑通了，再把 Mode 改回FDCAN_MODE_NORMAL，接上外部收发器和总线测试。

回环模式还有一个变体叫外部回环，FDCAN_MODE_EXTERNAL_LOOPBACK，信号会从 TX 引脚出去再通过外部收发器回到 RX 引脚。这个模式可以验证 PCB 上的收发器焊接是否正常，但需要收发器在位。

4. 常见问题与排查技巧实录

4.1 帧发不出去：先查邮箱状态

这是遇到最多的一个问题。代码逻辑看着没毛病，HAL_FDCAN_AddTxMessage也调了，但总线上一帧都抓不到。排查路径分三步：

第一步，检查HAL_FDCAN_AddTxMessage的返回值。如果不是HAL_OK，打印或者 RTT 输出一下具体类型。如果是HAL_BUSY，说明三个发送邮箱全满，上一批帧还没发完，这时候应该看看是不是主循环发送频率太高，或者某一帧卡在邮箱里没被硬件拿走。

第二步，检查总线状态。在fdcan.c初始化之后加一行：

printf("FDCAN State: %lu\n", HAL_FDCAN_GetState(&hfdcan1));

如果状态一直是HAL_FDCAN_STATE_BUSY而不是HAL_FDCAN_STATE_READY，说明初始化可能没完成。最常见的原因是时钟没起来——你配置了 FDCAN 使用 PLL1Q 作为时钟源，但 PLL 的使能位没有在SystemClock_Config里打开，导致 FDCAN 寄存器根本没法访问。

第三步，检查引脚复用。如果你用的是默认的 PB8/PB9 作为 FDCAN1 的 RX/TX，CubeMX 会自动配好复用功能，没问题。但如果你自己手动改过引脚，比如把 FDCAN1 映射到了 PD0/PD1，那就得仔细核对 AF 编号和GPIO_InitStruct里的Alternate参数，错一个 AF 都是白搭。

4.2 STM32H7A3 移植过来的工程启动报错

网络热搜里提到了 stm32h7a3 canfd 通讯，这里必须单独说一下 H7A3 和 G4 的移植差异。H7A3 的 FDCAN 时钟系统比 G4 复杂，它的 PLL2 输出可以到 320MHz，用高分频去推 FDCAN 经常能把速率配得很极限。而 G4 的 FDCAN 时钟上限没那么高，如果你把 H7A3 的配置原封不动搬过来，很可能出现初始化时位时序参数溢出、HAL_FDCAN_Init直接返回HAL_ERROR。

解决办法是重新按 G4 的时钟树算一遍位时序。比如你先确认 G4 的 FDCAN 时钟是多少，然后用 CubeMX 的 Bit Timing 页面去配，不要试图保留 H7 上的那组 raw register value，它们没有可移植性。

另外一个常见区别是中断向量名称。H7 上的 FDCAN 中断向量叫FDCAN1_IT0_IRQHandler，G4 上也是这个名字，但有些老版本 HAL 库生成的名字可能是FDCAN1_IT0_IRQHandler和FDCAN1_IT1_IRQHandler混用，需要在启动文件里确认一下有没有重复定义。

4.3 收不到数据：先看过滤器再查中断

收不到数据的排查顺序和发送不太一样。我一般先不动示波器，直接在代码里看两个东西：

第一，过滤器配置。如果过滤器把 ID 配错了，比如对端发的是扩展帧（29 位 ID），但你过滤器里写的是标准帧 ID，那这帧会被直接丢掉。这时候你可以先把过滤器设置成接收所有 ID：

FilterConfig.FilterID = 0; FilterConfig.FilterMask = 0; FilterConfig.FilterFIFOAssignment = FDCAN_RX_FIFO0; FilterConfig.FilterActivation = ENABLE;

掩码清零表示不过滤任何位，任意 ID 都能进。如果这样能收到数据，那就是过滤器配置的问题，再去针对性修改。

第二，检查接收 FIFO 里到底有没有数据。在HAL_FDCAN_GetRxMessage之前，可以先调用：

uint32_t fifoLevel = HAL_FDCAN_GetRxFifoFillLevel(&hfdcan1, FDCAN_RX_FIFO0);

如果这个值始终为 0，说明硬件层面就没有新帧进来，不用再往下查代码了，直接查总线物理连接。可能你的 TX/RX 接反了，可能收发器的 STBY 引脚没拉高，可能 CAN_H 和 CAN_L 之间没接 120 欧终端电阻。这些问题光靠软件看不出来，必须用万用表或者示波器量。

4.4 波特率不准：系统时钟偏差的锅

有时候通讯时好时坏，偶尔报错，帧率一高就掉链子。这种情况大概率不是配置问题，而是时钟精度问题。G4 的内置 HSI 时钟精度大约在 1%~2% 之间，如果 FDCAN 直接用 HSI 跑，波特率偏差会累积，特别是数据段跑到 5Mbps 的时候，偏差可能直接超过协议允许的容差范围。

解决办法有两个思路：

一是换用外部晶振。如果你的板子上有 8MHz 或 25MHz 晶振，把系统时钟改成 HSE + PLL 锁相环，精度能提升到 50ppm 以内，妥妥够用。

二是如果因为成本或者板面积原因只能用内部时钟，就要把数据段速率控制在 2Mbps 以下，同时把采样点尽量往后调（比如 85%），给误码留出更多冗余。

我自己在调试电池管理从机节点时吃过这个亏，当时为了省一颗晶振，直接用 HSI 跑 5Mbps，结果两对板子开始通信时好时坏，折腾了三天，最后换了无源晶振，一晚上都稳定。从那以后我只要碰 CAN-FD，一律上外部晶振，省那几毛钱不值得。

4.5 常见问题速查表

5. 从 G4 工程扩展到多节点与多 FDCAN 实例

这个工程包默认只用了 FDCAN1 一个实例，但 G4 系列很多型号带两个 FDCAN 控制器。如果你在做一个网关类项目，需要同时桥接两条总线，那可以继续扩展。

配置第二个 FDCAN 实例的思路几乎一模一样：在 CubeMX 里使能 FDCAN2，分配引脚，配置时钟和过滤器。需要注意的地方是，FDCAN2 和 FDCAN1 共用同一个时钟源，但各自的位时序参数是独立的，所以两条总线可以跑不同的速率。

在多实例场景下，中断处理的资源分配要考虑清楚。两个 FDCAN 实例的接收中断会各自触发回调函数，但 HAL 库默认只有一套回调函数入口。你需要根据hfdcan指针判断是哪个实例触发的：

void HAL_FDCAN_RxFifo0Callback(FDCAN_HandleTypeDef *hfdcan, uint32_t RxFifo0ItFlags) { if (hfdcan == &hfdcan1) { // 处理 FDCAN1 的帧 } else if (hfdcan == &hfdcan2) { // 处理 FDCAN2 的帧 } }

这种写法对于两个实例互通也成立。你可以把从 FDCAN1 收到的数据，稍作加工后通过 FDCAN2 转发出去，这就是一个最简单的网关雏形。实际项目中，我经常在这个基础上加上 ID 映射表，把不同子网里的节点 ID 翻译成目标子网能识别的 ID，实现跨网透传。

关于发送缓存的策略，再补充一点：多实例场景下，两个 FDCAN 的发送共用同一个中断优先级可能会产生竞争。建议把 FDCAN1 的优先级设得比 FDCAN2 高一点，优先保证靠近控制核心的那条总线不掉帧。这个优先级分配在 NVIC 里配置，不影响 FDCAN 外设本身的运行，但对于整体系统的实时性影响很明显。

6. 写在最后的实战心得

打开stm32g4_canfd.zip这个工程包，把配置从头到尾过了一遍，再结合我这几年调 CAN-FD 的经验，有一个体会特别深：CAN-FD 带来的不仅仅是速率提升，更大的变化在于开发者的调试思路——你不能再把 CAN 总线当成一个简单的“串口替代品”，而是必须把它当成一套有时序约束、有协议容差、有物理层考量的完整系统。

在这个工程里，CubeMX 能帮你解决 80% 的配置工作，但剩下 20% 的时钟适配、采样点微调、FIFO 中断分配、过滤器策略，还是得靠你对 FDCAN 控制器本身的机制有足够理解。比如哪怕只是把一个数据帧从 8 字节换成 64 字节，都要重新想清楚对端节点的 DMA 缓冲够不够、处理函数耗时会不会超过帧间隔、中间要不要加流控。这些问题，不是看一遍 datasheet 就能想明白的，得真的跑起来、报过错、丢过帧，才有感觉。

最后再分享一个我个人的小习惯：每次在陌生板子上跑 CAN-FD，我都会先开内部回环模式，然后发一个 64 字节的满帧，再用逻辑分析仪抓一下 TX 引脚的波形。确认波形上的 BRS 跳变沿和数据段的高速位时间正确之后，再切换到正常模式接外部总线。整个过程不超过十分钟，但这十分钟能帮你把“芯片配置问题”和“硬件外部问题”干净利落地切开，后面再做联调就顺很多。

这个工程包如果你能把它吃透，改成你自己的协议栈、诊断服务或者 Bootloader 刷写逻辑，都不会太难。FDCAN 这个外设是通用且成熟的，难点永远在你怎么用好它给的那几个自由度——时钟、位时间和帧格式。把这几个变量掌握住，G4 上的 CAN-FD 基本就稳了。

本文还有配套的精品资源，点击获取