第一次调 CAN 的时候板子焊好、程序烧进去、收发器也上了电结果上位机一条报文都抓不到示波器上 CAN_H 和 CAN_L 是一对安安静静的直线。那种感觉很难受——代码编译通过、没有报错、没有 HardFault可总线就是死的一样。后来才发现问题既不在芯片也不在代码逻辑而是一开始对 GD32F30x 这套 CAN 外设的理解就偏了它沿用的是 bxCAN 那一套模型硬件把大量工作做在了内部位时序、验收滤波、收发邮箱、错误计数软件要做的不是往寄存器里塞数据而是先把它的规则翻译成自己能掌控的参数。这篇文章讲的就是这件事围绕 GD32F30x 系列 MCU 上的 CAN 通信展开从外设形态、位时序推算、过滤器配置一路讲到收发代码骨架、实测排查链路和上层协议的分包设计。适合刚接手这类芯片、准备把 CAN 跑起来的嵌入式开发者也适合已经在用但被偶发丢帧总线关闭折腾过的人——文中给出的参数表、配置代码和排查顺序都可以直接拿去对照使用。1. 先把 F30x 的 CAN 外设摸透它不是发几个字节那么简单很多人从串口转过来做 CAN第一反应是不就是个带 ID 的串口吗。这个直觉会让你在后面每一步都踩坑。串口是点对点的发出去就完事收不到大不了查线CAN 是总线多个节点共享一对差分线任何一个节点的时序、电平、终端匹配出问题整条总线都可能被拖进错误状态。而 F30x 内部这套 CAN 控制器本质上是一个带状态机的协议引擎它替你做了位填充、CRC、应答、仲裁、错误计数这一整套事情代价是你必须按它的规矩来配置。1.1 CAN0/CAN1 的 bxCAN 血统与它在 F30x 上的实际形态GD32F30x 系列里的 CAN 外设属于 bxCAN 架构那一脉采用协议版本 2.0A 和 2.0B 的主动式设计支持标准帧11 位 ID和扩展帧29 位 ID最高速率可以跑到 1Mbps。大部分型号带两路 CAN编号 CAN0 和 CAN1其中 CAN1 是从控制器它不能独立做时间触发通信某些低引脚数封装干脆只引出一路。内部结构上有三个发送邮箱、两个接收 FIFOFIFO0 和 FIFO1每个 FIFO 深度是 3 级另外还有一组验收滤波器通常 14 组具体数量按型号查手册以及独立的收发错误计数器。这几个数字非常关键后面所有的设计取舍都围着它们转三个发送邮箱意味着你最多能同时挂三帧待发报文第四帧就必须等前面有空位。它不是无限缓冲的队列。每个 FIFO 只有 3 级深度意味着中断响应不及时第 4 帧就会覆盖或者丢失。这一点在做高频数据采集时特别要命。滤波器组是硬件的门卫配置错了报文压根不会进 FIFO你在中断里永远等不到。我一般建议在动手写代码之前先把所用具体型号的数据手册里 CAN 那一章翻一遍确认三件事有几路 CAN、滤波器组数量是多少、引脚复用关系是什么。型号后缀不同这些细节会变凭经验想当然是最容易翻车的地方。1.2 引脚、时钟、收发器三处最容易漏掉的硬件前提软件层面能跑通之前硬件上有三个前提必须先成立缺一个总线就起不来。第一是引脚复用。CAN0 默认走 PA11CAN_RX和 PA12CAN_TX也可以通过重映射搬到 PB8、PB9 上CAN1 默认是 PB12、PB13重映射后是 PB5、PB6。这里有个特别容易被忽略的点一旦用到重映射除了 GPIO 时钟还必须打开 AFIO 时钟并且调用重映射配置函数。少了这一步你会看到引脚上完全没有波形示波器一测就是死的。另外 CAN_RX 建议配成上拉输入CAN_TX 配成复用推挽输出速度等级选 50MHz 足够别选最低档。第二是时钟。CAN 挂在 APB1 总线上位时序的所有计算都基于 APB1 的时钟频率。F30x 主频常见的配置是 120MHzAPB1 通常做二分频得到 60MHz。假如你的工程里 APB1 时钟是别的值比如为了省电降到 30MHz那么同一套波特率参数算出来的实际速率就会差一倍表现出来就是配置明明一样就是通不上。我在排查别人工程时第一步永远是打印或者用调试器看一眼 RCU 里 APB1 的实际分频值而不是直接怀疑 CAN 代码。第三是收发器。MCU 出来的 CAN_TX/CAN_RX 是 TTL 电平必须经收发器转换成差分信号才能上总线。常见的高速 CAN 收发器比如 TJA1050 这一类 5V 器件需要供电、需要共地它的 TXD 接 MCU 的 CAN_TXRXD 接 CAN_RX。有些收发器还有 standby/silent 引脚硬件上如果悬空或者被拉到了静默电平芯片就只收不发你会在总线上看到自己发的报文没有、别人的报文却有——这种半瘫状态最难查。提示单独两块板对连时终端电阻必须有。标准是总线两端各一个 120 欧中间节点不要加。只有两块板的时候就是两个 120 欧并联用万用表量 CAN_H 和 CAN_L 之间应该读到 60 欧左右。读不到 60 欧先别动代码。1.3 工作模式的选择逻辑正常、回环、静默、静默回环F30x 的 CAN 控制器提供四种工作模式用对了能省掉大量调试时间模式行为典型用途正常模式正常收发参与仲裁与应答正式运行回环模式自发自收内部把 TX 环路回 RX不驱动总线无收发器时验证软件链路静默模式只收不发不产生显性位不应答监听总线、抓包不干扰静默回环自发自收且不驱动总线单板自测、协议栈联调这里我要强调一个经验回环模式是排查到底是硬件问题还是软件问题的分水岭。代码写完先切回环如果回环能收到自己发的帧说明位时序、过滤器、收发邮箱、中断这一整条软件链路是通的问题在硬件侧收发器、接线、终端电阻如果回环都收不到那就别去看硬件了老老实实查配置。这个二分法能省下至少一半的调试时间。2. 位时序的账要自己算从 60MHz 的 APB1 到 500kbps 的每一个 Tq波特率配置是 CAN 里最不能抄别人参数的一环。别人工程里写 prescaler4你抄过来发现通不上原因往往是两边的 APB1 时钟不一样或者采样点位置差太多导致远端的节点判错误帧。这一节我把账摊开算一遍。2.1 一个时间量子 Tq 拆开看CAN 的位时间被切成若干个时间量子Time QuantumTq一个位由三段组成同步段SYNC_SEG固定 1 个 Tq用于总线电平跳变对齐。时间段 1BS1包含传播段和相位缓冲段 1可配 1 到 16 个 Tq。时间段 2BS2相位缓冲段 2可配 1 到 8 个 Tq。所以位时间 1 BS1 BS2 个 Tq而每个 Tq 的长度由预分频值 prescaler 决定Tq prescaler / f_APB1。采样点位置 (1 BS1) / (1 BS1 BS2)。在 GD32 的固件库里prescaler字段填的是分频系数本身写入寄存器时硬件会自动减一所以填 6 就代表 6 分频不用自己手动减。BS1 和 BS2 则通过宏来选比如CAN_BT_BS1_15TQ、CAN_BT_BS2_4TQSJW 同步跳转宽度一般取 1Tq总线短、速率不高时这个值够了长总线或者多节点时钟偏差大的场景可以加到 2Tq 或 3Tq。2.2 常用波特率的参数对照与采样点取舍假设 APB1 60MHz下面这张表是我在实际项目里反复验证过的一组参数采样点统一压在 80% 附近这个位置在 CAN 规范推荐的 75%~87.5% 区间内兼容性最好。目标速率prescalerTq 长度位时间 Tq 数BS1BS2采样点1Mbps466.7ns1511380.0%800kbps583.3ns1511380.0%500kbps6100ns2015480.0%250kbps12200ns2015480.0%125kbps24400ns2015480.0%100kbps30500ns2015480.0%拿 500kbps 走一遍完整计算Tq 6 / 60MHz 100ns一个位 2μs正好 20 个 Tq1 15 4 20采样点 16/20 80%。数字都对得上。为什么不用极端的采样点如果采样点压到 87.5% 以上那么留给 BS2 的余量很小总线长度稍长一点信号传播延迟就会让采样落到错误的位边界上如果压到 70% 以下遇到时钟偏差时同样容易出错。80% 是很多工业设备的默认值选它最省心。另外 1Mbps 那行我用了 15 个 Tq 而不是 20 个因为 60MHz 下要凑 20 个 Tq 得用非整数分频15 个 Tq 配合 prescaler4 刚好整除误差为零。如果你手上的工程 APB1 不是 60MHz别改 BS1/BS2改 prescaler 最省事prescaler f_APB1 / (目标速率 × 位时间 Tq 数)。比如 APB1 是 36MHz要 500kbps、20 个 Tq那么 prescaler 36M / (500k × 20) 3.6不是整数就得把 Tq 数换成 181134或者 24118 不行超了18 时 prescaler 36M/(500k×18) 4正好整除。所以调波特率本质上是在整除和采样点之间找平衡先保证整除再微调 BS1/BS2 把采样点拉回 80% 附近。注意两端节点的位时序参数不一定要完全相同但波特率必须严格一致采样点也别差太远。我曾经遇到过一端 80%、一端 92.5% 的情况短帧没事长帧和高负载下偶发错误帧查了两天才定位到采样点。2.3 用回环模式做自检先把软件问题隔离出来配置完位时序别急着接总线。先把工作模式设成CAN_LOOPBACK_MODE自己发一帧看能不能进 FIFO。这一步能验证的东西很多CAN 时钟是否真的开了、位时序参数是否合法不合法的话控制器会进初始化失败状态、过滤器是否放行了这帧、接收中断是否配置正确。回环模式下有个细节值得说控制器不会真正驱动总线但内部的发送和接收是完整走一遍的包括验收滤波。所以如果回环收不到八成是过滤器没配对而不是接线问题。这个判断非常干净。3. 过滤器组决定你能收到什么掩码、列表与 FIFO 的分配策略姑且把 CAN 的收发分成两半看发送是我主动的逻辑直白接收是别人塞给我的必须先过门卫。这个门卫就是验收滤波器它是新手最容易栽的地方也是很多人调了半天发得出去收不回来的真正原因。3.1 掩码模式与列表模式的适用边界滤波器有两种工作模式选错了不是报错而是默默地过滤掉所有报文。掩码模式MASK给一个 ID 和一个掩码掩码位为 1 表示该位必须匹配为 0 表示不关心。适合我要一类 ID的场景比如只收 0x100~0x10F 这 16 个 ID掩码就能一次覆盖。列表模式LIST直接列出若干个精确 ID只有完全等于其中之一才放行。适合我只要指定的几帧的场景报文种类少的时候用它更直观。有个换算关系必须记住一组 32 位滤波器在掩码模式下管 1 个 ID 范围在列表模式下能存 2 个精确 ID一组 16 位滤波器在掩码模式下管 2 个 ID 范围分别对应两个 16 位寄存器列表模式下能存 4 个精确 ID。滤波器组数量有限怎么分配要看你的协议。我一般的做法是把周期性关键帧心跳、状态用列表模式精确匹配把一堆参数帧用掩码模式做区段放行剩下的直接开一组全通滤波器兜底避免漏帧。3.2 32 位与 16 位过滤器的位域映射这是最反人类的部分。32 位过滤器下标准帧的 ID 要左移到寄存器的 bit[31:21] 位置上扩展帧则要拆成高 16 位和低 16 位两部分16 位过滤器下标准帧 ID 放在 bit[31:21] 和 bit[15:5] 两个位置扩展帧只取高 16 位。写错一位滤波器就放行不了。我的经验是不要手算移位直接写成宏或者小函数用注释把位域画出来。比如标准帧 32 位过滤器/* 标准帧 11 位 ID 在 32 位过滤器中的位置 * bit31 .. bit21 STID[10:0] * bit20 EXID (0 表示标准帧) * bit19 IDE (0 表示标准帧) * bit18 RTR * bit17 .. bit0 保留 */ #define STD_ID_TO_FILTER(id) ((uint32_t)((id) 0x7FF) 21)扩展帧的话高 16 位是(id 13) 0xFFFF低 16 位是((id 3) 0xFFF8) | 0x04IDE 位置 1 表示扩展帧。这段代码我抄在自己所有项目的公共头文件里从来没再错过。3.3 一份能直接抄的过滤器配置与 FIFO 划分下面这段是初始化里最常用的组合CAN0 的 0 号滤波器组用 32 位掩码模式接收 0x100~0x1FF 区间的标准帧放进 FIFO01 号组用 32 位列表模式精确接收 0x210 和 0x220放进 FIFO1。can_filter_parameter_struct filter; /* 滤波器组 0掩码模式放行 0x100 ~ 0x1FF 到 FIFO0 */ can_struct_para_init(CAN_FILTER_STRUCT, filter); filter.filter_number 0; filter.filter_mode CAN_FILTERMODE_MASK; filter.filter_bits CAN_FILTERBITS_32BIT; filter.filter_list_high STD_ID_TO_FILTER(0x100); filter.filter_list_low 0x0000; filter.filter_mask_high STD_ID_TO_FILTER(0x700); /* 高 3 位必须匹配 */ filter.filter_mask_low 0x0000; filter.filter_fifo_number CAN_FIFO0; filter.filter_enable ENABLE; can_filter_init(filter); /* 滤波器组 1列表模式精确接收 0x210 和 0x220 到 FIFO1 */ can_struct_para_init(CAN_FILTER_STRUCT, filter); filter.filter_number 1; filter.filter_mode CAN_FILTERMODE_LIST; filter.filter_bits CAN_FILTERBITS_32BIT; filter.filter_list_high STD_ID_TO_FILTER(0x210); filter.filter_list_low STD_ID_TO_FILTER(0x220); filter.filter_fifo_number CAN_FIFO1; filter.filter_enable ENABLE; can_filter_init(filter);这里有两个必须注意的点。第一filter_enable一定要设成ENABLE忘了这一步前面全白配控制器不会报错就是收不到。第二can_struct_para_init这个调用别省它负责把结构体清成默认值不调用的话结构体里残留的栈上垃圾值会带来莫名其妙的行为。我见过一次滤波器偶发失效最后查出来是结构体没初始化某个字段恰好是随机值。关于 FIFO 的划分我的建议是按优先级来分而不是按ID 段来分。把实时性要求高的帧放 FIFO0用更高优先级的中断去处理把大数据量的参数帧放 FIFO1用较低优先级轮询或者低优先级中断处理。这样即使 FIFO1 处理慢也不会阻塞关键帧。4. 收发代码怎么写才不别扭邮箱、FIFO 与中断的配合配置对了代码写起来其实很轻。但这部分有一些看起来能跑、跑起来出问题的写法值得摊开说。4.1 发送三个邮箱的轮询与阻塞判断发送函数的返回值是邮箱编号如果三个邮箱都满它会返回失败。很多人在这里直接忽略返回值结果高负载时丢帧且毫无察觉。正确做法是先找一个空闲邮箱找不到就等或者降级处理。uint8_t can_send_std(uint32_t id, uint8_t *data, uint8_t len) { can_trasnmit_message_struct tx; uint8_t mailbox; /* 先看有没有空邮箱三个都用着就直接返回失败 */ if (can_transmit_states(CAN0, CAN_MAILBOX0) CAN_TRANSMIT_PENDING can_transmit_states(CAN0, CAN_MAILBOX1) CAN_TRANSMIT_PENDING can_transmit_states(CAN0, CAN_MAILBOX2) CAN_TRANSMIT_PENDING) { return 1; /* 邮箱满交给上层决定是重试还是丢弃 */ } can_struct_para_init(CAN_TX_MESSAGE_STRUCT, tx); tx.tx_sfid id; tx.tx_ff CAN_FF_STANDARD; tx.tx_ft CAN_FT_DATA; tx.tx_dlen len; for (uint8_t i 0; i len; i) { tx.tx_data[i] data[i]; } mailbox can_message_transmit(CAN0, tx); return (mailbox CAN_NOSTATUS) ? 1 : 0; }三个邮箱是硬件资源等一个空位和丢弃并计数是两种设计哲学。我的做法是控制类报文用等待配合超时状态上报类报文用丢弃加计数器让上层能知道丢了多少。千万不要用死循环等邮箱一旦总线进入错误状态、重传次数增加死循环会把整个任务卡死看门狗都救不回来。还有一个参数值得关注auto_retrans自动重传。默认使能时发送失败的帧会自动重发直到成功或者总线关闭。这在正常总线上是正确的行为但在调试阶段会让你误判我只发了一次为什么总线上有几十帧——那是因为没有节点应答控制器一直在重发。调试时我通常会临时关掉自动重传发一次就是一帧时序看得清楚。4.2 接收中断的完整骨架接收用中断最省心但中断里做的事要克制只把报文搬走、释放 FIFO复杂处理交给任务层。void CAN0_RX0_IRQHandler(void) { can_receive_message_struct rx; if (can_interrupt_flag_get(CAN0, CAN_INT_FLAG_RFNE0) ! RESET) { /* 把 FIFO 里的报文全部取空不要只取一帧 */ while (can_receive_message_length_get(CAN0, CAN_FIFO0) 0) { can_message_receive(CAN0, CAN_FIFO0, rx); ringbuf_put(can_rx_ring, rx); /* 只做搬运 */ } can_interrupt_flag_clear(CAN0, CAN_INT_FLAG_RFNE0); } }这里的核心是while循环。每个 FIFO 深度是 3如果中断里只读一帧就返回剩下的两帧会在下次中断才被处理一旦中断延迟变大就直接溢出。用循环把 FIFO 读空再把数据丢进环形缓冲区是最稳妥的写法。环形缓冲区的大小按你的最大突发流量来定我一般给 32 到 64 帧。提示接收中断的优先级别设太高也别设太低。太高会打断更关键的实时任务太低会在高负载时丢帧。我通常把它放在中等偏上的位置比串口高比电机控制环低。4.3 错误中断与总线关闭的恢复CAN 控制器内部有两个错误计数器发送错误计数 TEC 和接收错误计数 REC。计数超过 255 时进入总线关闭Bus-Off状态节点自动退出总线不再收发。这时候如果没做恢复你的设备就成了哑巴而代码还在正常跑日志里什么都看不到。F30x 支持自动总线关闭恢复ABOM使能后硬件会在检测到 128 次连续 11 个隐性位之后自动恢复。我建议把这个选项打开同时再使能错误中断做记录can_interrupt_enable(CAN0, CAN_INT_ERR); /* 错误中断 */ can_interrupt_enable(CAN0, CAN_INT_BO); /* 总线关闭中断 */ nvic_irq_enable(CAN0_EWMC_IRQn, 2, 0);在错误中断里我会读一下错误状态寄存器把 TEC/REC 和错误类型打到日志里。这个信息在排查现场问题时价值极高——如果 TEC 一直涨说明你的帧没人应答或者仲裁一直失败多半是波特率不对如果 REC 涨说明你收到的帧有错误多半是对端时序有问题或者线太长。5. 板子通不了电就有报文把排查链路走一遍我把这些年遇到的 CAN 不通问题归了一下类按排查成本从低到高排个序照着走能覆盖九成情况。5.1 总线起不来的排查链路第一步永远是量电阻。断电万用表量 CAN_H 和 CAN_L应该在 60 欧左右两个 120 欧终端并联。如果是 120 欧说明只有一个终端如果是无穷大说明一个都没有如果是 40 欧说明有人多接了。这一步三十秒能排除掉一大堆问题。第二步看波形。上电示波器差分探头或者两个单端探头相减看有没有帧。如果完全没有查 MCU 引脚——CAN_TX 上应该有明显的方波跳变哪怕总线没应答它也会发出去然后报错重传。如果 CAN_TX 有波形但 CAN_H/CAN_L 没变化问题在收发器供电、使能脚、焊接。第三步如果波形有但全是错误帧那就回到位时序。拿示波器量一个位的宽度500kbps 应该是 2μs量出来是 4μs 就说明你的 APB1 时钟算错了实际速率是 250kbps。第四步如果单节点自测正常、多节点不通检查 ID 冲突和波特率一致性。我遇到过一次两个节点的固件版本不同一个用 500k、一个用 250k表现就是两边都疯狂报错谁都发不出去。5.2 偶发丢帧与 FIFO 溢出偶发丢帧最隐蔽因为大部分时候是好的。判断方法很直接在接收中断里统计 FIFO 溢出标志溢出时硬件会置位相应标志跑一段时间看有没有计数。如果有说明你的中断处理太慢或者被更高优先级的中断长时间屏蔽了。解决思路有三条按优先级排一是缩短中断里的处理时间只做搬运不做解析二是加大环形缓冲区三是把 FIFO1 也用起来让两个 FIFO 分担流量。我一般不推荐靠提高中断优先级来解决那只是把问题转移给了别的模块。还有一个容易忽略的点如果rec_fifo_overwrite设成使能新报文会覆盖最老的一帧看起来没丢实际丢的是旧数据且没有任何提示。调试阶段建议关掉覆盖让它老老实实报溢出。5.3 重映射与引脚冲突用重映射把 CAN0 搬到 PB8/PB9 的时候务必确认三件事AFIO 时钟已开、调用了重映射配置函数、PB8/PB9 没有被别的外设占用。我遇到过一块板子上 PB9 同时接了 LED结果 CAN 一开LED 就跟着闪总线也时通时断。这种硬件层面的冲突软件上怎么调都是白费劲。另外提醒一句重映射配置函数调用之后不要再去改 GPIO 的模式顺序错了会把复用功能覆盖掉。正确的顺序是开时钟 → 配 GPIO 模式 → 配重映射 → 配 CAN 外设。5.4 采样点不匹配导致的远端节点错误帧这个坑我在一个多节点项目里踩过。本地测试一切正常接上第三方的设备后跑几分钟就出一次错误帧。最后用分析仪抓出来问题在采样点我们用 80%对方用 92.5%在长帧、高负载、线缆偏长的组合下对方的采样点落到了我们信号的边沿附近偶尔判错。处理办法是把采样点往中间收双方都调整到 80% 附近同时把 SJW 从 1Tq 加到 2Tq给时钟偏差留出余量。这件事让我养成了一个习惯新项目接入第三方节点之前先问清楚对方的位时序参数而不是假设大家都用默认值。6. 从能通到敢上车分包、心跳与节点状态管理单帧收发跑通只是起点。真实项目里你要传的数据往往超过 8 字节要判断对方是不是还活着要在出错时优雅降级。这部分是应用层的活但设计得好不好决定了后期维护成本。6.1 多帧报文的分包与重组CAN 一帧最多 8 字节一条 100 字节的配置数据得拆成十几帧。我的做法是在应用层定义一个极简的传输协议头部 2 字节第一字节低 4 位是序列号0~15 循环高 4 位是标志首帧/中间帧/末帧第二字节是总长度。接收端维护一个按发送方 ID 索引的重组缓冲收到首帧清空缓冲、记录总长中间帧按序列号顺序追加末帧到了就交付上层。这里有个必须处理的边界如果中间丢了一帧怎么办靠序列号检测。序列号不连续就丢弃整包并请求重发。超时也要有从收到首帧开始计时比如 200ms 内没收齐就复位重组状态。不做这两个保护你会遇到半包永远卡在缓冲里下一个包来了拼在一起的诡异现象。分包大小也要考虑。我一般不把 8 字节塞满留 1 到 2 字节给序列号和长度实际数据 6 字节一帧。虽然传输效率低一点但调试时抓包一眼就能看懂帧结构很值。6.2 心跳、超时与节点状态管理总线上有多少节点、谁在线、谁掉线这套逻辑必须显式做。我的做法是每个节点以 100ms 周期发一帧心跳ID 固定为 0x700 节点号数据域第一字节是状态码后面是运行时间低字节。所有节点维护一张节点表收到心跳就把对应节点的超时计数清零并置在线标志主循环里每 10ms 扫描一次超过 500ms 没收到就标记离线。离线之后怎么办取决于业务。安全相关的场景要立刻进入安全状态比如输出归零非安全场景可以重试几次再判断。千万不要检测到掉线就重启整个系统总线抖动一下全员重启那场面很壮观。6.3 一套可复用的模块分层我现在习惯把 CAN 相关代码分成三层这个分层在几个项目里都验证过迁移起来很轻层次职责是否与芯片相关驱动层时钟、引脚、位时序、滤波器、中断注册强相关换芯片要重写传输层环形缓冲、分包重组、超时、重发弱相关基本可复用应用层报文语义解析、节点状态机、业务逻辑完全无关驱动层对外只暴露四个接口初始化、发送一帧、注册接收回调、获取错误统计。传输层对上只暴露发送一个包注册包回调。这样换芯片时只改驱动层那一个文件传输层和应用层一行不动。我做过的移植里最快的一次半天就完成了因为所有的协议逻辑都没碰。还有一个小技巧在驱动层加一个统计结构体记录发送成功数、发送失败数、接收数、FIFO 溢出数、错误中断次数、总线关闭次数。运行中可以通过一个调试报文把这些数字发出来现场排查问题时非常有用——比让客户去接串口打印靠谱得多。最后分享一个我自己的习惯新板子第一次上电我一定先跑回环自测把发一帧收一帧打出来确认软件链路没问题再去碰总线和收发器。这个顺序看起来慢实际上比直接上总线然后一头雾水地猜快得多。CAN 这个外设的脾气就是——配置对了它极其稳定配置错一个位它一句话都不说。所以真正花时间的从来不是写代码而是把每一个参数背后的账算清楚。