4. CAN 错误处理机制：错误类型与错误状态机
大家好，我是你们的老朋友。今天我们来聊聊CAN总线里一个特别重要、也特别容易被忽视的话题——错误处理机制。
说实话，我刚入行那会儿，总觉得CAN通信嘛，只要硬件连对了，软件配置好了，数据就能稳稳地跑。直到有一次，我在一个新能源项目的台架测试中，发现电机控制器时不时丢报文，整车报“通信超时”故障。排查了整整两天，最后发现是总线上的一个节点进入了“总线关闭”状态。嗯，从那以后，我再也不敢小看CAN的错误处理了。
你想想看，一辆车在路上跑，电磁干扰、线束老化、连接器松动，这些都是家常便饭。如果没有一套健壮的错误处理机制，CAN总线早就乱成一锅粥了。今天我就带你彻底搞懂CAN的错误类型和状态机。
4.1 错误类型：CAN总线上的“五宗罪”
CAN协议定义了五种错误类型。说白了，就是总线上的节点发现数据不对劲时，能识别出具体是哪出了问题。我个人习惯把这五种错误分成两类：位层面的错误和帧层面的错误。
4.1.1 位错误（Bit Error）
这是最基础、也最直接的一种错误。规则很简单：发送节点在发送每一位时，会同时监听总线上的电平。如果它发送的位和监听到的位不一致，就立即报位错误。
举个例子：你发送了一个显性位（逻辑0），但总线上却读到的是隐性位（逻辑1）。这说明总线被其他节点干扰了，或者你的发送电路出了问题。
关键点：位错误只在发送节点上检测。接收节点不会报位错误，因为接收节点本来就不需要“发送后再监听”。
我的经验：我在一个项目中遇到过，某款MCU的CAN控制器在低温环境下偶尔报位错误。后来发现是晶振温漂导致位时序偏差，发送的位刚好落在采样点边缘。解决办法是重新校准了CAN的波特率配置，把采样点从75%调整到了80%。
4.1.2 填充错误（Stuff Error）
CAN协议规定：在发送连续5个相同电平的位之后，必须插入一个相反电平的填充位。这个机制是为了保证总线上的电平有足够多的跳变，方便接收节点同步时钟。
填充错误，就是接收节点发现总线上出现了连续6个或更多相同电平的位。这说明发送节点没有按规则插入填充位，或者总线被干扰了。
为什么会这样？说白了，如果发送节点的填充逻辑出了bug，或者总线上的噪声恰好把填充位给“吞掉”了，接收节点就会检测到连续6个相同位，立刻报填充错误。
注意：CRC界定符、ACK界定符、EOF这些固定格式的段，是不做位填充的。别搞混了。
4.1.3 CRC错误（CRC Error）
CRC（循环冗余校验）是CAN帧里最强大的错误检测手段。发送节点会计算整个帧的CRC校验码，放在CRC段里。接收节点收到帧后，用同样的算法重新计算一遍CRC。如果计算结果和收到的CRC码不一致，就报CRC错误。
CRC错误通常意味着数据在传输过程中被严重干扰了。我在项目中见过最典型的场景：电机控制器大功率运行时，强电磁干扰导致CAN总线上的数据包CRC校验失败率飙升到5%以上。后来通过优化双绞线的屏蔽层接地，才把错误率降下来。
| 错误类型 | 检测方 | 检测时机 | 典型原因 |
|---|---|---|---|
| 位错误 | 发送节点 | 发送每一位后 | 总线竞争、硬件故障 |
| 填充错误 | 接收节点 | 接收数据帧时 | 发送节点填充逻辑异常、噪声干扰 |
| CRC错误 | 接收节点 | 接收CRC段后 | 电磁干扰、线束过长 |
| 格式错误 | 接收节点 | 接收固定格式段时 | 协议解析异常、位错误连锁反应 |
| ACK错误 | 发送节点 | 发送ACK槽后 | 总线上无其他节点、接收节点故障 |
4.1.4 格式错误（Form Error）
CAN帧里有些段的格式是固定的，比如CRC界定符必须是隐性位，ACK界定符必须是隐性位，EOF必须是7个隐性位。如果接收节点发现这些固定格式的位不是预期的电平，就报格式错误。
格式错误通常不是独立发生的。它往往是其他错误的“并发症”。比如位错误导致某个位被翻转，恰好把CRC界定符从隐性变成了显性，接收节点就会报格式错误。
4.1.5 ACK错误（Acknowledgment Error）
这个错误只有发送节点会检测。规则是：发送节点在ACK槽期间发送一个隐性位，然后监听总线。如果总线上没有出现显性位（即没有其他节点确认收到），就报ACK错误。
说白了，就是发送节点发现“我发了消息，但没人理我”。这种情况通常意味着总线上只有这一个节点在工作，或者所有接收节点都处于故障状态。
避坑指南：我曾经在一个项目中，发现某个节点偶尔报ACK错误。排查了半天，发现是它的CAN收发器的RS引脚（斜率控制）配置不当，导致显性位驱动能力不足，其他节点收不到有效的显性ACK信号。换了一款收发器就好了。
4.2 错误状态机：从“好孩子”到“被开除”
光能检测错误还不够，CAN协议还定义了一套完整的错误状态机，用来管理每个节点的“健康状态”。每个节点内部有两个计数器：发送错误计数器（TEC）和接收错误计数器（REC）。这两个计数器决定了节点处于哪个状态。
你想想看，如果一个节点频繁出错，说明它可能硬件坏了，或者受到了严重干扰。如果让它继续在总线上“捣乱”，会拖垮整个通信网络。所以CAN协议设计了三个状态：
- 主动错误状态（Error Active）：正常状态，节点可以正常收发，出错时发送主动错误帧。
- 被动错误状态（Error Passive）：警告状态，节点可以收发，但出错时只能发送被动错误帧。
- 总线关闭状态（Bus Off）：隔离状态，节点完全退出总线，不再参与任何通信。
4.2.1 状态转换规则
状态转换的规则其实很简单，我总结成一张表你就明白了：
| 当前状态 | 转换条件 | 转换后状态 |
|---|---|---|
| 主动错误 | TEC > 127 或 REC > 127 | 被动错误 |
| 被动错误 | TEC > 255 | 总线关闭 |
| 被动错误 | TEC ≤ 127 且 REC ≤ 127 | 主动错误 |
| 总线关闭 | 检测到128次11个连续隐性位（总线空闲） | 主动错误 |
这里有个细节要注意：REC超过127也会进入被动错误状态。也就是说，一个节点即使自己不发送数据，只是“听”数据，如果它接收到的错误太多，也会被降级。
核心逻辑：CAN的错误计数器设计得非常巧妙。发送错误每次加8，接收错误每次加1。这意味着发送节点犯错要付出更大的代价。为什么？因为发送节点犯错对总线的破坏更大——它可能发送了错误的数据帧，或者发送了错误帧干扰其他节点。
4.2.2 三种状态的行为差异
不同状态下，节点的行为有什么不同？我直接说重点：
- 主动错误状态：节点检测到错误后，发送主动错误帧（6个连续显性位）。这个错误帧的优先级很高，会强制打断当前正在传输的帧，让所有节点都知道出错了。
- 被动错误状态：节点检测到错误后，发送被动错误帧（6个连续隐性位）。注意，隐性位不会覆盖总线上的显性位。所以如果总线上有其他节点在发送主动错误帧，被动错误帧根本起不了作用。说白了，被动错误节点“说话没人听”。
- 总线关闭状态：节点完全沉默，不发送任何帧，也不接收任何帧。它需要等待总线空闲（连续11个隐性位）出现128次，才能自动恢复到主动错误状态。
重要提醒：总线关闭状态的恢复时间不是固定的。它取决于总线空闲的时间。如果总线一直繁忙，节点可能永远恢复不了。在实际项目中，我建议在应用层增加一个超时监控，如果节点长时间处于总线关闭状态，主动触发硬件复位。
4.2.3 错误计数器的增减规则
很多初学者搞不清TEC和REC到底怎么加减。我直接给你一个简化版：
- 发送节点成功发送一帧：TEC减1（前提是TEC > 0）
- 接收节点成功接收一帧：REC减1（前提是REC > 0）
- 发送节点检测到错误：TEC加8
- 接收节点检测到错误：REC加1
- 发送节点在发送错误帧或过载帧时检测到位错误：TEC加8
这个规则设计得很精妙。你想想看，发送节点犯错一次加8，成功一次才减1。这意味着一个节点如果连续犯错，TEC会迅速飙升到127甚至255以上，很快就被“踢出群聊”。而接收节点犯错一次只加1，说明协议对接收节点更宽容——毕竟接收节点只是“听错了”，不是“说错了”。
我的经验：我曾经调试过一个故障，某个节点频繁进入总线关闭状态。用CAN分析仪抓包发现，它的TEC在短时间内从0飙升到256。进一步分析发现，这个节点的CAN控制器时钟配置有误，导致它发送的位时序偏差太大，其他节点总是报位错误。而这个节点收到其他节点的错误帧后，又误以为自己的发送有问题，继续加TEC。恶性循环，最终被总线关闭。
4.3 错误帧的结构
最后简单提一下错误帧。当节点检测到错误时，它会发送一个错误帧来通知其他节点。错误帧由两部分组成：
- 错误标志：6个连续相同电平的位。主动错误节点发6个显性位，被动错误节点发6个隐性位。
- 错误界定符：8个隐性位。
错误帧的优先级非常高。它可以在任何帧的任何位置插入（包括帧起始、仲裁场、数据场等）。这就是为什么CAN总线的实时性这么好——一旦出错，立刻就能被检测并纠正。
好了，关于CAN的错误处理机制，我就讲到这里。总结一句话：CAN的错误处理机制，本质上是一套“犯错-记过-降级-开除”的管理系统。理解了这个逻辑，你就能轻松应对各种CAN通信故障了。
下一章，我会带你深入CAN的位时序和同步机制。那是真正考验硬件功底的地方，咱们到时候见。