2. CAN通信故障排查：CAN总线物理层故障、数据链路层故障、应用层超时与错误帧分析
CAN总线，说白了就是ECU之间的“对话通道”。通道出了问题，车就跑不起来。我这些年排查过的CAN故障，少说也有上百例了。今天就把最常见的三类问题——物理层、数据链路层、应用层——掰开揉碎了讲清楚。
2.1 物理层故障：终端电阻与线束问题
物理层是CAN通信的“地基”。地基不稳，上面再好的协议也白搭。我个人习惯，遇到CAN通信问题，先拿万用表量物理层。
2.1.1 终端电阻
CAN总线两端各需要一颗120Ω的终端电阻。为什么是120Ω？因为CAN双绞线的特性阻抗大约是120Ω，匹配电阻能消除信号反射。
关键检查点：
- 断电状态下，测量CAN_H与CAN_L之间的电阻。正常值约60Ω（两颗120Ω并联）。
- 如果测到120Ω，说明只有一端有电阻，另一端缺失。
- 如果测到0Ω或接近0Ω，说明CAN_H与CAN_L短路了。
- 如果测到无穷大，说明总线断路或电阻全部丢失。
我在项目中遇到过一台车，CAN通信时好时坏。查了半天，发现是终端电阻焊点虚焊。温度一高，焊点断开，电阻失效。温度降下来又接上了。这种“软故障”最坑人。
我的小技巧： 测量终端电阻时，最好把ECU全部断电。有些ECU内部有偏置电阻，会影响测量结果。我习惯断开蓄电池负极再测。
2.1.2 线束短路与断路
线束问题分三种：CAN_H对地短路、CAN_H对电源短路、CAN_H与CAN_L互短。断路则常见于接插件松动或线束折断。
| 故障类型 | CAN_H电压 | CAN_L电压 | 差分电压 |
|---|---|---|---|
| 正常（隐性） | 2.5V | 2.5V | 0V |
| 正常（显性） | 3.5V | 1.5V | 2V |
| CAN_H对地短路 | 0V | 2.5V | -2.5V |
| CAN_H对电源短路 | 12V | 2.5V | 9.5V |
| CAN_H与CAN_L互短 | 2.5V | 2.5V | 0V（但无法通信） |
你想想看，如果CAN_H对地短路了，差分电压变成负的，接收器根本识别不了。这时候总线就“瘫痪”了。
避坑指南： 我曾经遇到过一台车，CAN_L对电源短路，电压飙到12V。结果烧掉了三个ECU的CAN收发器。从那以后，我排查线束短路时，一定先确认电源是否断开。带电插拔CAN线，也是大忌。
2.2 数据链路层故障：ID冲突与波特率不匹配
物理层没问题，但通信还是不正常？那就要看数据链路层了。说白了，就是“对话规则”出了问题。
2.2.1 ID冲突
CAN总线是广播式通信，每个报文都有唯一的ID。如果两个节点用同一个ID发送报文，就会产生总线仲裁错误。
为什么会这样？嗯，这里要注意：CAN的仲裁机制依赖ID的优先级。两个节点同时发送相同ID时，仲裁无法区分谁该让路，结果就是错误帧。
排查方法：
- 用CAN分析仪抓取总线报文，观察是否有连续的“错误帧”或“过载帧”。
- 查看错误计数器（TEC/REC）。如果某个节点的REC快速增加，说明它接收到了错误。
- 逐一断开节点，看错误帧是否消失。消失的那个节点就是“捣乱分子”。
我记得有一次，供应商提供的两个ECU用了同一个ID。他们说是“巧合”，但车就是跑不起来。最后改了其中一个的ID，问题解决。所以，DBC文件一定要仔细核对。
2.2.2 波特率不匹配
CAN总线上所有节点的波特率必须一致。常见的有125kbps、250kbps、500kbps。波特率不匹配，节点之间根本“听不懂”对方在说什么。
怎么判断？用示波器看CAN_H上的位时间。500kbps的位时间是2μs，250kbps是4μs。量一下就知道了。
我的习惯： 新项目启动时，我会在DBC文件里明确标注波特率，并在每个ECU的标定文档里写清楚。曾经有个项目，两个团队用了不同的波特率，联调时浪费了两天。说白了，就是沟通不到位。
2.3 应用层超时与错误帧分析
物理层和数据链路层都正常，但应用层还是报错？这时候就要看“超时”和“错误帧”了。
2.3.1 应用层超时
CAN协议本身不定义超时，但应用层会定义。比如，ECU_A每隔10ms发送一次报文。如果ECU_B在20ms内没收到，就认为通信超时。
超时的原因通常有：
- 发送节点死机或程序跑飞。
- 总线负载过高，报文被延迟发送。
- 接收节点的中断优先级设置不当，导致报文丢失。
我在项目中遇到过，一个ECU的CAN接收中断被更高优先级的中断抢占。结果报文来了，CPU没空处理，直接丢包。超时报警就出来了。后来调整了中断优先级，问题解决。
避坑指南： 我曾经以为超时一定是发送端的问题。后来发现，接收端的软件架构不合理，也会导致超时。排查时，两边都要看，别只盯着发送方。
2.3.2 错误帧分析
错误帧是CAN总线自己发出的“求救信号”。常见错误帧类型：
- 位错误： 发送节点监控总线，发现发送的电平与监控到的电平不一致。
- 填充错误： 连续5个相同电平后，没有插入相反电平。
- CRC错误： 接收节点计算的CRC与发送节点的不一致。
- 形式错误： 帧格式不符合规范。
- 应答错误： 发送节点没收到应答信号。
怎么分析？用CAN分析仪抓取错误帧，看错误类型和错误计数器。如果错误帧集中在某个ID上，大概率是那个节点有问题。
实战案例： 有一台车，跑高速时偶尔报“CAN通信丢失”。我抓了一天数据，发现错误帧全是“CRC错误”。进一步排查，发现是线束过长，信号衰减导致CRC计算不一致。缩短线束后，问题消失。
你想想看，错误帧就像CAN总线的“咳嗽声”。偶尔咳一声没事，一直咳就说明病了。病根可能在物理层，也可能在节点本身。
2.4 总结
CAN通信故障排查，我习惯按这个顺序来：
- 先量物理层：终端电阻、线束通断、电压水平。
- 再看数据链路层：ID是否冲突、波特率是否一致。
- 最后分析应用层：超时设置、错误帧类型。
说白了，就是“由下往上”排查。别一上来就怀疑软件，很多时候问题就出在线上。嗯，今天就聊到这儿。下一章我们讲LIN通信的故障排查，那个也有不少坑。