4. CAN错误处理：错误类型与故障界定
各位同学，今天我们来聊聊CAN总线里一个特别实在的话题——错误处理。
说实话，我刚入行那会儿，觉得CAN通信嘛，不就是发发报文、收收数据？直到有一次，我在一个车载项目中，整车网络突然出现间歇性通信中断。排查了三天三夜，最后发现是一个节点的错误计数器爆了，被总线“隔离”了。从那以后，我深刻认识到：不懂错误处理，你根本玩不转CAN。
CAN协议之所以能在汽车这种高噪声、高可靠性的环境中存活几十年，靠的就是它那套精密的错误检测与故障界定机制。说白了，它不仅能发现错误，还能自动把“捣乱”的节点踢出局，保证总线继续正常工作。
4.1 五种错误类型
CAN协议定义了五种错误类型。我习惯把它们分成两类：“报文内容错了”和“报文格式错了”。咱们一个一个来看。
4.1.1 位错误（Bit Error）
这是最基础的一种错误。发送节点在发送每个位的同时，会监控总线电平。如果它发送的是显性位（0），却读到了隐性位（1），或者反过来——那就说明总线上的实际电平和它想发的不一致，这就是位错误。
关键点：位错误只在发送节点身上发生。接收节点不会报位错误，因为接收节点本来就不需要“发送”电平。
我在项目中遇到过一种情况：两个节点配置了相同的标识符，同时开始发送。结果总线上一片混乱，位错误疯狂爆发。嗯，这就是典型的标识符冲突。
4.1.2 填充错误（Stuff Error）
CAN协议规定：连续发送5个相同电平的位之后，必须插入一个相反电平的位。这叫“位填充”。
为什么这么做？你想想看，接收节点需要从总线信号中提取时钟信息。如果长时间没有电平跳变，接收器的锁相环就会失锁。所以，填充规则保证了总线信号有足够的跳变沿。
如果接收节点检测到连续6个相同电平的位——那就是填充错误。说白了，发送方没按规矩来。
我的经验：填充错误通常意味着发送节点的位时序配置有问题，或者晶振偏差太大。我曾经调试过一个项目，某ECU的晶振精度只有0.5%，结果在高速CAN（1Mbps）下频繁出现填充错误。换成1%精度的晶振后，问题消失。
4.1.3 CRC错误（CRC Error）
CRC（循环冗余校验）是CAN帧的“指纹”。发送节点根据报文内容计算出一个15位的CRC序列，放在帧里。接收节点收到后，用同样的算法重新计算一遍。
如果计算结果和收到的CRC序列不匹配——那就是CRC错误。
CRC错误是最常见的错误类型之一。为什么？因为总线上的噪声干扰、信号反射、终端电阻不匹配，都可能导致数据位被翻转。CRC就是用来捕获这些随机错误的。
| 错误类型 | 检测方 | 典型原因 |
|---|---|---|
| 位错误 | 发送节点 | 总线冲突、驱动能力不足 |
| 填充错误 | 接收节点 | 位时序偏差、晶振误差 |
| CRC错误 | 接收节点 | 噪声干扰、信号反射 |
| 形式错误 | 接收节点 | 协议违规、软件bug |
| 应答错误 | 发送节点 | 无节点接收、ACK掩码错误 |
4.1.4 形式错误（Form Error）
CAN帧的某些字段有固定的电平要求。比如：CRC界定符必须是隐性位（1），ACK界定符也必须是隐性位。如果接收节点在这些固定区域检测到了显性位（0），那就是形式错误。
形式错误说白了就是“格式不对”。我见过最奇葩的一次：某个节点的软件工程师把CRC界定符写成了显性位，结果整个网络都在报形式错误。排查了两天才找到原因——代码里一个宏定义写错了。
4.1.5 应答错误（ACK Error）
发送节点在发送完CRC序列后，会释放总线，等待接收节点在ACK槽位发送显性位（0）作为应答。如果发送节点在ACK槽位读到了隐性位（1）——那就是应答错误。
这意味着：没有节点成功接收这个报文。
注意：应答错误并不一定意味着总线故障。如果发送节点的标识符没有被任何接收节点配置为接收对象，那它自然收不到ACK。这在多网络网关设计中经常遇到。
4.2 错误状态机
好了，现在我们知道CAN能检测五种错误。但检测到错误之后呢？节点该怎么反应？
CAN协议定义了一个错误状态机，每个节点都有两个计数器：
- 发送错误计数器（TEC）：记录发送错误次数
- 接收错误计数器（REC）：记录接收错误次数
根据这两个计数器的值，节点处于三种状态之一：
我画了一张图，帮你理清这个状态机的流转逻辑：
4.2.1 错误主动（Error Active）
这是节点的正常状态。TEC和REC都小于127。在这个状态下，节点检测到错误时，会发送主动错误标志——连续6个显性位（000000）。这个标志会覆盖总线上的其他信号，强制所有节点知道发生了错误。
说白了，错误主动节点是个“暴脾气”，一发现错误就大声嚷嚷，让所有人都停下来。
4.2.2 错误被动（Error Passive）
当TEC或REC超过127时，节点进入错误被动状态。这时候，节点检测到错误后，发送的是被动错误标志——连续6个隐性位（111111）。
注意：被动错误标志不会覆盖总线上的显性位。也就是说，其他节点可能根本听不到它的“呼喊”。
我个人的理解：错误被动节点就像被“禁言”了。它还能接收和发送报文，但它的错误报告已经没有“杀伤力”了。这是CAN协议的一种保护机制——防止一个频繁出错的节点干扰整个网络。
4.2.3 总线关闭（Bus Off）
当TEC超过255时，节点进入总线关闭状态。这是最严重的状态——节点完全断开与总线的连接。它不再发送任何报文，也不再接收任何报文。
要退出总线关闭状态，节点需要检测到128次连续的11个隐性位（总线空闲序列）。这通常需要硬件复位或软件干预。
避坑指南：我曾经在一个项目中，某个节点频繁进入总线关闭状态。排查后发现，是它的CAN控制器配置错误，导致发送的报文格式不对，每次发送都触发应答错误。TEC一路飙升到255。解决方案很简单——修正配置，但排查过程花了整整两天。所以，遇到总线关闭，先检查发送节点的配置。
4.3 故障界定机制
CAN的错误处理机制，本质上是一个分布式故障界定系统。每个节点独立判断自己的健康状况，不需要中央控制器。
这套机制的核心逻辑是：
- 谁犯错，谁负责：发送错误只增加TEC，接收错误只增加REC。发送节点如果频繁出错，TEC会快速上升，最终被总线关闭。
- 好节点不受牵连：如果一个节点频繁发送错误报文，其他节点虽然会收到CRC错误或形式错误，但它们的REC增长很慢。而发送节点的TEC增长很快。
- 恢复机制：每次成功发送或接收报文，对应的计数器会递减。所以，只要节点能恢复正常通信，计数器会慢慢降下来。
我举个例子你就明白了：
假设节点A的CAN驱动器坏了，输出波形畸变。节点B和C每次收到A的报文都会报CRC错误，REC加1。但A自己呢？它发送的位可能被总线上的显性位覆盖，触发位错误，TEC加8。几次下来，A的TEC就超过255了，被总线关闭。而B和C的REC可能才十几。
你看，坏节点被踢出局，好节点继续工作。这就是故障界定的精髓。
我的建议：在实际项目中，建议在ECU的软件中增加错误计数器的读取接口。通过诊断服务（比如UDS的0x22服务）读取TEC和REC值，可以快速定位问题节点。我在多个项目中都用这个方法，效果很好。
4.4 小结
CAN的错误处理机制，说白了就是一套“自治愈”系统。五种错误类型覆盖了通信中可能出现的各种问题，错误状态机保证了单个节点的故障不会拖垮整个网络，故障界定机制则让系统能自动隔离问题节点。
嗯，这里要特别提醒一点：很多工程师在设计CAN网络时，只关注波特率和报文周期，忽略了错误处理机制。但实际项目中，80%的CAN通信问题都和错误处理有关。所以，花时间理解这套机制，绝对值得。
下次调试CAN网络时，不妨先看看节点的错误计数器。它往往能告诉你问题出在哪里。
公众号:蓝海资料掘金营，微信deep3321