4. CAN错误处理机制：错误类型分类、错误计数规则、总线关闭状态恢复
各位工程师，咱们今天聊聊CAN总线里一个特别关键的话题——错误处理。说实话，很多刚入行的朋友觉得错误处理就是个辅助功能，能跑就行。但我在项目里吃过亏，才明白这东西要是搞不清楚，车在路上跑着跑着总线就罢工了，那可不是闹着玩的。
4.1 错误类型分类：五种错误，各有各的脾气
CAN协议定义了五种错误类型。我习惯把它们分成两类：一类是“格式不对”，另一类是“内容不对”。你想想看，总线上的节点就像一群人在开会，有人说话声音太小、有人抢话、有人说的内容前后矛盾——这些都得管。
| 错误类型 | 检测层级 | 触发条件 | 我见过的典型场景 |
|---|---|---|---|
| 位错误（Bit Error） | 发送节点 | 发送位与总线电平不一致 | 总线短路时，发送显性位却读到隐性位 |
| 填充错误（Stuff Error） | 所有节点 | 连续6个相同电平位 | 晶振偏差大时，位时序错乱导致填充规则被破坏 |
| CRC错误（CRC Error） | 接收节点 | CRC校验和与本地计算不一致 | 电磁干扰强的环境下，数据被篡改 |
| 形式错误（Form Error） | 所有节点 | 固定格式位域出现非法电平 | ACK槽或EOF段被错误拉低 |
| 应答错误（ACK Error） | 发送节点 | ACK槽未收到显性位 | 总线上只有一个节点，或者接收器全部离线 |
这里有个细节我得提一下：位错误只有发送节点能检测。为什么？因为只有发送节点知道自己发的是什么。接收节点只能看到总线上的电平，它没法判断这个电平是不是发送者想要的。嗯，这个逻辑其实很朴素。
核心要点：五种错误中，位错误和应答错误是发送节点的“专属检测”，其他三种是所有节点都能参与的“公共检测”。
4.2 错误计数规则：两个计数器，一套加减法
每个CAN节点内部都有两个计数器：发送错误计数器（TEC）和接收错误计数器（REC）。说白了，这就是给节点记“黑账”的。我当年调试一个ECU时，就靠盯着这两个计数器的变化，找到了总线被干扰的根源。
规则其实不复杂，我总结成几句话：
- 发送节点出错了：TEC加8。为什么加8？因为发送节点犯错影响大，惩罚重一些。
- 接收节点出错了：REC加1。接收节点只是“听错了”，惩罚轻一些。
- 发送节点成功发送：TEC减1。但有个前提——TEC必须大于0才能减。
- 接收节点成功接收：如果REC在1~127之间，减1；如果REC为0，保持不变；如果REC大于127，直接降到127以下再减。
你可能会问：为什么接收成功时，REC大于127要特殊处理？
我个人理解是这样的：当REC超过127时，节点已经处于“被动错误”状态了。这时候如果它成功接收一帧，说明总线可能正在恢复，给它一个“快速减分”的机会，让它尽快回到正常状态。这个设计很人性化，对吧？
实战技巧：我在调试时，习惯用CAN工具同时监控TEC和REC。如果发现某个节点的TEC持续增长，基本可以断定它的收发器或晶振有问题。如果REC普遍增长，那多半是总线物理层的问题——比如终端电阻没匹配好。
4.3 错误状态机：三种状态，三级警戒
根据TEC和REC的数值，节点会处于三种状态之一。我管它叫“三级警戒”：
| 状态 | 条件 | 行为特征 |
|---|---|---|
| 错误主动（Error Active） | TEC < 128 且 REC < 128 | 正常收发，检测到错误时发送主动错误帧（6个显性位） |
| 错误被动（Error Passive） | TEC ≥ 128 或 REC ≥ 128 | 仍可收发，但只能发送被动错误帧（6个隐性位），且发送前需等待8个隐性位 |
| 总线关闭（Bus Off） | TEC > 255 | 完全退出总线，不发送任何帧，不参与任何通信 |
这里有个容易踩的坑：错误被动状态下，节点发送的被动错误帧是隐性位。这意味着其他节点可能根本“听不见”这个错误帧！我曾经在一个项目中，某个节点进入了错误被动状态，它一直在发错误帧，但其他节点完全没反应，因为隐性位被总线的显性位覆盖了。结果这个节点越错越多，最后直接总线关闭了。
避坑指南：我曾经遇到过一台ECU，因为电源纹波过大，导致TEC缓慢增长到128以上。进入错误被动后，它发送的被动错误帧被其他节点忽略，TEC继续增长直到255，最终总线关闭。整个过程中，其他节点完全不知道发生了什么。所以，一定要在诊断协议里加入读取TEC/REC的服务，否则这种“慢性死亡”很难排查。
4.4 总线关闭状态恢复：两种策略，各有千秋
节点一旦进入总线关闭状态，就彻底“失联”了。怎么让它回来？CAN协议给了两种恢复方式：
4.4.1 自动恢复（推荐方式）
节点在检测到总线关闭后，会启动一个128个总线空闲周期的等待计时。每个总线空闲周期是11个隐性位（即一个帧间空间）。所以总等待时间是：128 × 11 = 1408个位时间。
举个例子：如果总线速率为500kbps，每个位时间是2μs，那么恢复时间就是1408 × 2μs ≈ 2.8ms。嗯，这个时间其实很短，但前提是总线必须保持空闲。
关键点：自动恢复期间，节点会持续监测总线。如果总线上有活动，它会重置计时器，重新开始计数。所以，如果总线一直繁忙，节点可能永远无法恢复。
4.4.2 手动恢复（调试用）
通过应用层命令强制节点退出总线关闭状态。这通常用于开发调试阶段。我习惯在Bootloader里加一个“强制恢复”命令，方便产线测试。
手动恢复的典型流程：
1. 应用层发送诊断请求 0x31 01 XX（复位通信）
2. ECU收到后，将TEC和REC清零
3. 节点立即恢复通信，无需等待128个空闲周期
我的建议：量产车上一定要用自动恢复。手动恢复只适合开发阶段。为什么？因为如果节点频繁总线关闭，手动恢复只是“治标不治本”，反而掩盖了物理层或软件层的根本问题。
4.5 实战中的错误处理策略
说了这么多理论，最后分享几个我在项目里用过的策略：
- 监控TEC/REC阈值：在应用层设置一个预警值，比如TEC超过100时就记录DTC。这样可以在节点进入错误被动之前就发现问题。
- 区分错误类型：位错误和填充错误通常指向硬件问题（晶振、收发器、终端电阻）。CRC错误和形式错误则可能指向软件问题（报文配置错误、ID冲突）。
- 总线关闭后的恢复策略：如果节点因为瞬时干扰而总线关闭，自动恢复是合理的。但如果节点在短时间内反复总线关闭（比如1分钟内超过3次），我建议让它保持关闭状态，并记录故障码。否则，频繁的恢复和关闭反而会干扰总线上的其他节点。
- 利用CAN控制器的中断：大多数CAN控制器（如SJA1000、MCP2515）都提供了错误状态变化中断。我习惯在中断服务函数里记录错误计数和时间戳，方便事后分析。
最后说一句：CAN的错误处理机制，说白了就是一套“自我净化”系统。它允许节点犯错，但不容忍节点一直犯错。理解了这个设计哲学，你就能更好地利用它来提升系统的鲁棒性。
好了，这一章就到这里。下一章咱们聊聊CAN网络管理——那些让节点“睡觉”和“起床”的规矩。