4、CANFD错误处理：CANFD错误帧类型、错误计数器机制、总线关闭恢复策略
说到CANFD的错误处理，我脑子里立刻浮现出几年前的一个项目。当时我们在做一款新能源车的BMS系统，CANFD总线动不动就掉线，搞得整个团队焦头烂额。后来才发现，就是错误处理机制没吃透。今天咱们就把这块硬骨头啃下来。
4.1 CANFD错误帧类型
CANFD的错误帧，说白了就是节点发现不对劲时发出的“求救信号”。它跟传统CAN一样，也分五种错误类型。但CANFD的帧结构更复杂，所以错误检测的点位也更多。
我个人习惯把这五种错误分成两类：帧内错误和帧间错误。
4.1.1 位错误（Bit Error）
这是最常见的一种。发送节点在发送位的同时，会监控总线电平。如果监控到的电平跟自己发的不一致，就报位错误。嗯，这里要注意：在仲裁场和应答间隙，这个规则是例外的——仲裁时多个节点同时发，电平冲突是正常的。
我在项目中遇到过一个问题：某款收发器的驱动能力不足，导致隐性位被误判为显性位。排查了整整两天，最后换了个收发器型号就解决了。
4.1.2 填充错误（Stuff Error）
CANFD用了位填充规则——连续5个相同电平后，必须插入一个相反电平。如果接收节点发现连续6个相同电平，就报填充错误。
这里有个CANFD特有的坑：数据场长度变了。传统CAN最多8字节，CANFD能到64字节。数据越长，填充位越多，出错的概率也越大。我曾经在一个项目中，就因为填充错误频繁触发，不得不把数据场长度从64字节降到32字节。
4.1.3 格式错误（Form Error）
固定格式的位段如果出现了非法电平，就报格式错误。比如CRC界定符、ACK界定符，这些位段的值是固定的，不能乱改。
4.1.4 应答错误（ACK Error）
发送节点在ACK槽位没有收到显性应答，就报应答错误。说白了就是：我喊了一嗓子，没人理我。
4.1.5 CRC错误（CRC Error）
接收节点计算出的CRC值跟发送节点的不一致。CANFD的CRC算法比传统CAN更复杂，支持17位和21位两种CRC。数据场超过16字节时用21位CRC，否则用17位。
关键区别：CANFD的CRC覆盖范围更大，包含了填充位计数器等信息。这意味着CANFD的CRC校验比传统CAN更严格，但也更消耗计算资源。
4.2 错误计数器机制
每个CANFD节点都有两个错误计数器：发送错误计数器（TEC）和接收错误计数器（REC）。这两个计数器决定了节点的工作状态。
你想想看，为什么要有计数器？直接报错不就完了？其实不然。总线上偶尔出现一个错误是正常的，比如电磁干扰。但如果错误频繁出现，说明节点或者总线有问题了。计数器就是用来区分“偶然错误”和“持续故障”的。
4.2.1 计数规则
| 事件 | TEC变化 | REC变化 |
|---|---|---|
| 发送节点检测到位错误 | +8 | 不变 |
| 接收节点检测到CRC错误 | 不变 | +1 |
| 发送节点成功发送 | -1 | 不变 |
| 接收节点成功接收 | 不变 | -1（如果REC>0） |
| 节点进入主动错误状态 | +8 | +8 |
这个表格我建议你记下来。我在调试时经常要对照这个表来分析错误日志。有一次，我发现某个节点的TEC一直在128附近徘徊，说明它处于被动错误状态，但又不至于离线。后来查出来是它的晶振精度不够，导致位时序偏差。
4.2.2 节点状态机
根据错误计数器的值，节点会处于三种状态之一：
- 主动错误状态（Error Active）：TEC < 128 且 REC < 128。节点正常参与通信，检测到错误时发送主动错误帧（6个显性位）。
- 被动错误状态（Error Passive）：TEC > 127 或 REC > 127。节点可以参与通信，但检测到错误时只能发送被动错误帧（6个隐性位）。说白了就是“我错了，但我没力气喊了”。
- 总线关闭状态（Bus Off）：TEC > 255。节点彻底退出总线，不再发送任何数据。
个人经验：被动错误状态是最难排查的。因为节点还在发数据，但错误帧是隐性的，其他节点可能根本注意不到。我建议在开发阶段，把节点的错误状态通过诊断报文上报，方便调试。
4.3 总线关闭恢复策略
节点进入总线关闭状态后，怎么恢复？这里有几种策略，我按推荐程度排个序。
4.3.1 自动恢复（推荐）
节点检测到总线关闭后，等待128个连续的11位隐性位（即128个总线空闲序列），然后自动恢复。这是CANFD标准推荐的方案，也是大多数控制器默认的行为。
为什么是128个？我理解这是一种“冷静期”。让节点冷静一下，等总线上的错误风暴过去再说。
4.3.2 快速恢复（慎用）
有些控制器支持快速恢复模式，等待时间可以缩短到96个甚至更少。但我不建议在生产环境中用。我曾经在一个项目中用了快速恢复，结果节点反复进入总线关闭又快速恢复，导致总线上的错误帧像放鞭炮一样。最后改回标准恢复才稳定下来。
4.3.3 手动恢复
通过应用层软件主动复位控制器。这种方式给了上层软件最大的控制权。比如，可以记录总线关闭的次数，如果短时间内频繁关闭，就彻底停止通信并上报故障。
避坑指南：我曾经遇到过一个案例，某个节点进入总线关闭后，自动恢复了，但它的TEC并没有清零。结果恢复后没多久又关闭了。后来发现是驱动库的bug，恢复时没有正确重置计数器。所以，恢复后一定要检查TEC是否真的归零了。
4.4 实践建议
说了这么多理论，最后给几条实战建议：
- 监控错误计数器：在开发阶段，把TEC和REC通过CAN报文发出来。我习惯用0x700-0x7FF的诊断地址来上报。
- 设置合理的恢复策略：对于安全关键系统（如刹车、转向），建议用手动恢复，并且记录错误日志。对于非安全系统（如娱乐、空调），自动恢复就够了。
- 注意CANFD的位时序：CANFD的位时间更短，对时钟精度要求更高。如果晶振误差超过1%，建议用带PLL的控制器。
- 测试总线关闭场景：在实验室里，故意制造总线短路、断路等故障，观察节点的恢复行为。我见过太多项目，在实验室跑得好好的，一上车就出问题。
好了，CANFD的错误处理就讲到这里。下一章咱们聊聊CANFD的物理层设计，包括终端电阻、线束拓扑这些实战内容。到时候我会分享一个我在某主机厂看到的“神级”布线方案，保证让你大开眼界。