4. CAN总线错误处理：错误类型与错误状态机
大家好，我是你们的讲师。今天我们来聊聊CAN总线里一个特别重要、也特别容易被忽视的话题——错误处理。
说实话，我刚入行那会儿，总觉得CAN通信挺稳定的，错误处理嘛，了解一下就行。直到有一次，我在一个车载项目中，发现ECU时不时就“掉线”了，查了三天三夜，最后发现是错误状态机没处理好，节点自己把自己“关禁闭”了。从那以后，我再也不敢小看错误处理了。
你想想看，汽车在高速上跑着，如果CAN总线因为一个错误就罢工了，那后果不堪设想。所以，CAN协议设计了一套非常完善的错误检测和恢复机制。今天我们就把它彻底讲透。
4.1 五种错误类型
CAN协议定义了五种错误类型。说白了，就是五种“犯规”方式。任何节点只要发现其中一种，就会立刻上报。
| 错误类型 | 检测位置 | 触发条件 |
|---|---|---|
| 位错误 | 发送节点 | 发送的位与总线上的位不一致 |
| 填充错误 | 所有节点 | 连续出现6个相同电平位 |
| CRC错误 | 接收节点 | 计算出的CRC与接收到的CRC不匹配 |
| 格式错误 | 所有节点 | 帧格式不符合规范（如固定位为显性却读到隐性） |
| 应答错误 | 发送节点 | 发送节点在应答槽未收到显性位 |
4.1.1 位错误
位错误是最直接的错误。发送节点在发送一个位的同时，会监控总线上的实际电平。如果发现不一致，就说明出问题了。
举个例子：你发送了一个显性位（0），但总线上读回来是隐性位（1）。为什么？可能是另一个节点同时发送了相反的位，或者总线被干扰了。
关键点：位错误只在发送节点检测。接收节点不检测位错误，因为接收节点本来就不需要“发送”位。
我在项目中遇到过一种情况：两个节点配置了相同的ID，同时发送数据。结果就是位错误频发，整个网络乱成一锅粥。嗯，这属于设计阶段的低级错误，但排查起来真让人头大。
4.1.2 填充错误
CAN协议有个“位填充”规则：连续发送5个相同位后，必须插入一个相反位。这是为了保持同步。
填充错误，就是检测到连续6个相同位。这意味着发送节点没有遵守填充规则，或者总线被干扰了。
我个人习惯在调试时特别关注填充错误。为什么？因为它往往暗示着时钟同步问题。如果某个节点的晶振偏差太大，就容易在填充逻辑上出岔子。
4.1.3 CRC错误
CRC（循环冗余校验）是数据完整性的最后一道防线。发送节点会计算整个帧的CRC值，放在帧尾。接收节点收到后，重新计算一遍，比对一下。
如果不一致，就是CRC错误。这说明数据在传输过程中被篡改了。
小技巧：CRC错误率是衡量总线质量的重要指标。如果CRC错误率超过1%，我建议你检查一下总线终端电阻、线缆屏蔽和节点布局。
4.1.4 格式错误
格式错误，说白了就是“帧长得不对”。CAN帧的某些位是固定值，比如CRC界定符必须是隐性位。如果读到显性位，那就是格式错误。
我曾经遇到过一个奇葩问题：某个节点在发送扩展帧时，把IDE位搞反了。结果所有接收节点都报格式错误。排查了整整一天，最后发现是代码里一个宏定义写错了。嗯，这种错误最折磨人。
4.1.5 应答错误
应答错误只发生在发送节点。发送节点在应答槽（ACK Slot）发送一个隐性位，然后等待接收节点拉成显性位。如果没人拉，说明没有节点成功接收。
你想想看，如果总线上只有一个节点在发，没有接收节点，那应答错误就会一直出现。这在某些测试场景下是正常的，但在实际系统中，如果出现应答错误，通常意味着接收节点出了问题。
4.2 错误状态机
好了，五种错误类型讲完了。但CAN总线不会因为一次错误就把节点干掉。它有一套“三振出局”的机制——错误状态机。
每个CAN节点内部都有两个计数器：
- 发送错误计数器（TEC）：发送错误时加8，发送成功时减1
- 接收错误计数器（REC）：接收错误时加1，接收成功时减1
根据这两个计数器的值，节点处于三种状态之一：
| 状态 | 条件 | 行为 |
|---|---|---|
| 错误主动 | TEC < 127 且 REC < 127 | 正常通信，检测到错误时发送主动错误帧（6个显性位） |
| 错误被动 | TEC > 127 或 REC > 127 | 可以通信，但检测到错误时发送被动错误帧（6个隐性位） |
| 总线关闭 | TEC > 255 | 完全断开与总线的连接，不发送任何数据 |
4.2.1 错误主动状态
这是正常状态。节点发现错误后，会发送一个“主动错误帧”——6个连续的显性位。这会把当前正在传输的帧破坏掉，让所有节点都意识到出错了。
主动错误帧的威力很大，因为它会强制打断总线。但好处是，错误能被快速发现和恢复。
4.2.2 错误被动状态
当错误次数多了，节点就进入“错误被动”状态。这时候，节点虽然还能收发数据，但发送错误帧时只能发“被动错误帧”——6个连续的隐性位。
隐性位不会破坏总线上的显性位。所以，被动错误帧对其他节点的影响很小。但这也意味着，这个节点发出的错误信号可能被忽略。
避坑指南：我曾经在一个项目中，发现某个节点频繁进入错误被动状态，但其他节点完全没察觉。结果这个节点发出去的数据经常是错的，导致系统行为异常。所以，我建议你在应用层也监控一下错误状态，不要完全依赖硬件自动处理。
4.2.3 总线关闭状态
这是最严重的状态。当TEC超过255时，节点会主动断开与总线的连接。它不再发送任何数据，也不再接收任何数据。说白了，就是“自暴自弃”了。
总线关闭后，节点需要等待128个连续的隐性位（总线空闲）才能自动恢复。这个恢复过程是硬件自动完成的，不需要软件干预。
但要注意：如果节点频繁进入总线关闭状态，说明硬件或软件有严重问题。我建议你在代码里记录一下总线关闭的次数，作为诊断依据。
4.3 错误恢复机制
CAN总线的错误恢复机制，说白了就是“犯错-重传”。
当任何节点检测到错误时，它会发送错误帧。错误帧会破坏当前正在传输的数据帧。然后，所有节点都回到空闲状态，等待重新发送。
发送节点会自动重传被破坏的帧。重传的优先级和原帧一样，所以不会出现“插队”的情况。
这里有个细节：错误帧的优先级比数据帧高。所以，错误帧一旦发出，所有数据帧都得让路。这也是为什么错误处理要谨慎——频繁的错误帧会严重影响总线利用率。
个人经验：我在调试CAN总线时，习惯用示波器抓一下错误帧。如果看到连续的错误帧，那基本可以断定是某个节点出了问题。这时候，我会逐个断开节点，找到“罪魁祸首”。
4.4 实战建议
好了，理论讲完了。最后给大家几条实战建议：
- 监控错误计数器：在应用层定期读取TEC和REC，记录到日志中。这能帮你快速定位问题节点。
- 设置错误阈值：不要等到总线关闭才报警。我建议在TEC超过100时就发出警告。
- 区分错误类型：位错误和填充错误通常与硬件相关，CRC错误和格式错误可能与软件相关。对症下药。
- 测试总线负载：在开发阶段，故意制造一些错误（比如拔掉一个节点），看看系统的容错能力。
嗯，关于CAN总线错误处理，今天就讲到这里。记住，错误处理不是“锦上添花”，而是“雪中送炭”。在汽车电子领域，一个可靠的错误处理机制，往往比功能本身更重要。
下一章，我们会聊聊CAN总线的高级应用——CANopen协议。敬请期待。