尧图网站建设 
1. 错误帧不是故障是总线在喊救命做CAN总线调试这么多年我最怕听到的一句话不是又丢帧了而是示波器上全是乱七八糟的波形。乱波形背后十有八九是错误帧在刷屏。先说个很多新手容易搞混的概念错误帧不等于故障。CAN协议里内置了五套错误检测机制任何节点发现总线上有不符合规则的信号都会立刻往总线上发一段错误帧来通知所有人——这条消息作废赶紧重发。所以错误帧本质上是CAN总线自我保护的一种机制它像人体免疫系统里的白细胞不是病本身而是身体在报警。真正常见的场景是免疫系统太敏感或者外界刺激太频繁导致总线整天都在喊救命正常消息反而发不出去了。这篇文章不打算讲那种错误帧的五个类型及其定义的教科书内容那个标准协议文档里写得清清楚楚。我想聊的是实际排查中更值钱的东西每一种错误帧出现时总线上到底发生了什么、你该从哪个层面去查、示波器上看到什么波形能快速锁定方向。适合刚接手CAN调试的工程师也适合那些已经被偶发错误帧折磨了几个星期、想换个排查思路的老手。我自己的经验是CAN错误帧的排查八成的坑集中在物理层但八成的排查时间却耗在了软件层。这个比例如果能反过来你的调试效率能提升一大截。下面按我实际排查时的思考路径把五种错误帧挨个拆开讲。2. 五种错误类型逐个拆解触发条件与字节级表现CAN协议定义了五种错误检测机制任何一条报文在发送或接收过程中触犯了其中任何一条都会生成错误帧。别看只有五条它们分属不同检测层级定位方向截然不同。2.1 位错误Bit Error发送者最敏感的自检位错误是五种错误里最微妙的一种。规则很简单发送节点在发送一个显性位逻辑0或隐性位逻辑1时会实时监控总线电平如果发现自己发的是显性但总线上读到的是隐性或者反过来——自己发隐性但读到显性——立刻判定位错误。这里有个关键细节很多人忽略只有在仲裁段和ACK槽发送时发送节点才能容忍这种不一致。仲裁时故意发送隐性位但读到显性位说明有更高优先级的节点在争夺总线这是正常现象不触发错误帧。ACK槽同理发送节点发隐性位但接收节点回显性位表示应答这也是正常的。真正触发位错误报警的场合是数据段、CRC段这些位置出现电平读写不一致。最常见的物理根因有两个一是总线上的信号反射或沿过缓导致发送节点采样到的电平和自己刚发出的不一致二是两个节点波特率偏差过大采样点对不上。2.2 填充错误Stuff Error连续电平的规则破坏者CAN协议规定在SOF到CRC段之间如果出现连续5个相同电平的位发送方必须插入一个反相位的填充位。接收方则在收到连续5个相同电平位后会期待第6位是反相的填充位。如果第6位依然同相直接判定填充错误。为什么要有位填充规则简单说就是为了保证总线上的跳变沿密度。CAN节点恢复时钟依赖总线上的电平跳变如果长时间没有跳变沿节点间的采样时钟会逐渐漂移最终导致采样错误。位填充机制本质上是一种时钟同步的保障手段。这类错误在实际项目里出现频率不算高但它一出现往往意味着更底层的时序问题。我遇到过的案例是某个节点晶振偏差过大波特率实际值和标称值差了好几千ppm导致它在发送长串相同位时填充位的插入时机和其他节点的采样窗错位被误判为填充错误。这种问题光看软件没用得用高精度示波器量实际波特率。2.3 CRC错误CRC Error数据完整性的最后防线CRC循环冗余校验错误是接收节点最容易发现、也最容易误判的一类错误。每个CAN帧的CRC段包含发送节点对前面所有位计算出的15位CRC序列接收节点收到完整帧后用同样的算法重新计算一遍如果结果对不上就判定CRC错误。这里有个容易踩的坑接收节点报CRC错误不代表CRC计算逻辑有问题更多时候是物理层干扰导致帧内容在传输过程中变了。比如总线附近有强电磁干扰把某个显性位打成了隐性位或者信号反射导致某个位的电平在采样点附近抖动采样结果和发送端不一致。CRC错误是果真正的因往往在波形质量上。排查CRC错误时不要一上来就怀疑MCU的CAN控制器坏了或者软件配置错了先拿示波器看波形。重点关注显性/隐性电平幅值是否达标、边沿是否陡峭、有没有振铃和台阶、总线空闲时噪声幅度多大。我见过一个项目CAN_H和CAN_L之间的电容没匹配好导致高速传输时波形出现明显过冲跑几十帧就出一帧CRC错误换了个匹配电容后问题彻底消失。2.4 格式错误Form Error协议帧结构的守护者格式错误针对的是帧格式中那些固定电平的位段比如EOF帧结束的7个隐性位、CRC段的定界符、ACK定界符等。这些位置的位电平是协议写死的如果接收节点在这些位置采样到错误电平就会触发格式错误。格式错误里有个很典型的场景是EOF段End of Frame帧结束段。正常帧结束是7个隐性位如果第7位之前出现显性电平接收节点就会报格式错误。这个显性电平是谁拉低的多半是某个节点在帧还没结束时抢着发消息而这种抢发行为通常是因为它对帧结束位置的判断提前了。什么情况下会判断提前最常见的是波特率不匹配。节点A的波特率比节点B快A会认为帧已经结束开始发下一帧的SOF这个SOF的显性电平在B看来恰好落在EOF段里于是B报格式错误同时A可能也会因为仲裁失败报位错误。所以格式错误频繁出现时先检查各节点的实际波特率和采样点配置大概率能发现问题。2.5 应答错误Ack Error孤独发送者的呐喊应答错误的机制特别有意思。每个CAN帧的ACK槽发送节点会发送一个隐性位任何正确接收到该帧的节点需要在这个位置拉一个显性位来表示我收到了。如果发送节点在ACK槽采样到的仍是隐性位——也就是说没有任何节点应答它——就会判定应答错误。应答错误出现时最先要查的是总线上到底有几个节点这个发送节点是不是孤零零地挂在一条没有其他节点或者其他节点都处于静默状态的总线上这里有个新手常犯的误区往总线上接一个USBCAN盒子打开软件发送报文然后发现软件一直报无应答或ACK错误。原因很简单USBCAN只有发送节点这一个角色没有其他节点接收自然没人应答。但还有一种隐蔽情况发送节点和接收节点的波特率偏差过大接收节点虽然能收到部分位但CRC校验失败按协议规定CRC错误的接收节点不会发送ACK应答。于是发送节点看到的是——自己发出去的消息没人认领——报Ack Error。这种场景里Ack Error只是表象根因是波特率偏差别搞混了。3. 从物理层到链路层错误帧排查的分层思维排查错误帧最大的忌讳是东一榔头西一棒子。我的习惯是分层排查先物理层再数据链路层最后才是软件应用层。这个顺序不是随便定的而是因为物理层的故障占比最高而且如果不先排除物理层问题数据链路层和软件层排查出来的结论往往是不可靠的。3.1 物理层三板斧终端电阻、共地、线缆质量先看终端电阻。CAN总线规范要求线缆两端各接一个120欧姆终端电阻作用是吸收信号反射。如果缺了其中一个或者电阻值偏差太大总线上的信号会出现振铃和过冲轻则降低抗干扰能力重则直接产生位错误和CRC错误。测量终端电阻的办法很简单在总线断电状态下用万用表从任意一个节点处测量CAN_H和CAN_L之间的电阻。正常的总线架构下两个120欧姆并联实际测量值应该在60欧姆左右。如果测出来是120欧姆说明只有一端接了电阻如果测出来是无穷大说明两端都漏接了电阻。再说共地。CAN总线虽然是差分信号理论上可以容忍一定的共模电压差但CAN收发器的共模输入范围是有限的通常在-12V到12V之间具体看型号。当两个节点的地电位差过大时即使差分信号正常共模电压也会超出收发器的承受范围导致信号无法正确识别。我在现场排查过一个典型案例一个设备间相距两百多米的CAN总线偶尔出现错误帧但频率不高大概每分钟一两帧。用示波器挂在总线上看波形完全正常。后来量了两个设备之间的地电位差发现高达3.8V已经接近收发器共模范围的极限。原因是一个设备的地线电阻偏大负载一启动地电位就往上飘。解决方案是在两个设备之间加一条粗的地线错误帧直接清零。最后看线缆。CAN总线推荐使用双绞线而且绞距要均匀。如果用的是平行线或者在某个位置把双绞线破开了一段这段线缆相当于一个天线既容易引入干扰也容易向外辐射。另外要注意线缆的远离原则动力线、高频信号线要和CAN总线保持足够距离交叉时尽量垂直交叉避免长距离平行走线。3.2 波特率与采样点数据链路层最容易被忽略的隐性杀手波特率不匹配是CAN错误帧里最隐蔽的根因之一。注意我说的不一定是不匹配哪怕是标称值完全一样但由于晶振精度不同、CAN控制器分频配置不同实际波特率也会有细微偏差。CAN协议要求所有节点的位时间误差在一定范围内典型值是±0.5%以内具体看波特率和采样点配置。如果两个节点的晶振都是误差±100ppm的普通晶振理论上没问题但如果配置的采样点太靠后或者SJW同步跳转宽度设得太小就可能在某些位序列下触发错误帧。采样点的概念值得展开说说。CAN的一个bit时间分为同步段、传播段、相位缓冲段1和相位缓冲段2。采样点位于相位缓冲段1和相位缓冲段2之间合理的采样点位置通常在75%到85%之间。如果采样点太靠前信号还处于不稳定状态就采样容易采到错误的电平如果太靠后留给相位同步的缓冲余量不够在波特率有偏差时容易采错。我曾经排查过一个极其烦人的问题一辆车上的两个ECU标称波特率都是500kbps程序配置看起来也正常但就是偶尔出现错误帧而且只在特定温度下出现。后来用示波器分别抓两个ECU的波形发现一个采样点在80%另一个实际算下来只有68%虽然都能正常工作但偏差容限很窄。一旦温度变化引起晶振频率偏移误差就超过了容忍范围开始报错误帧。调整一个ECU的采样点配置到80%后问题彻底消失。所以排查错误帧时如果物理层波形看着正常建议用CAN分析仪把总线的实际波特率测出来再查各节点的采样点配置。不要盲目相信代码里的配置值MCU的CAN外设时钟源计算有坑有时候你以为配的是500k实际出来的可能是496k。3.3 CAN分析仪的正确打开方式不只是用来看很多工程师手里有CAN分析仪但用得不充分。分析仪不光是用来发报文、收报文的它还是定位错误帧位置和类型的利器。主流CAN分析仪比如周立功的USBCAN、Vector的CANalyzer或者一些国产工具都支持总线统计功能可以实时显示错误帧的数量和类型。有些高级功能还能记录错误帧发生时刻总线上的其他报文这对排查某个特定报文触发错误帧的问题特别有帮助。我强烈建议排查错误帧时把分析仪挂在总线上开启总线统计同时用示波器探头也挂在CAN_H和CAN_L上打开示波器的CAN解码功能。这样当错误帧发生时你能同时看到错误类型是什么、错误发生的帧是哪个ID、波形上哪一段出现了异常。三路信息一对照定位速度快得惊人。还有一个容易被忽视的小技巧CAN分析仪本身也有接收容错能力。如果分析仪报告的错误帧率和车上ECU错误计数器表现出来的症状对不上很可能是分析仪的采样点配置和车上ECU不一致导致分析仪看到的错误帧和ECU看到的不是同一批。这时候要把分析仪的采样点也调到和ECU一致才能拿到准确的数据。4. 四次实战排查案例从偶发丢帧到系统崩溃理论说得再多不如来几个实际案例直观。下面这几个案例都是我这些年真实处理过的场景各有代表性我把当时的排查链路完整写出来希望能帮大家建立一个可复制的排查思路。4.1 案例一新装节点后系统疯狂报错——终端电阻缺失这个案例特别典型适合作为入门案例。现象客户反馈在原来的CAN网络里新增了一个设备后整个网络开始疯狂报错甚至出现总线瘫痪。拆掉新增设备一切恢复正常。初步判断新增设备带崩了整个总线但具体原因不明。很多人第一反应是新增设备的软件有bug疯狂发错误帧。但仔细一想CAN总线的错误帧机制本身有容错能力单个节点的软件bug理论上不应该让整个总线瘫痪。排查过程先用万用表测量总线两端的终端电阻正常。再测新增设备的CAN接口发现CAN_H和CAN_L之间的阻抗是无穷大——新增设备内部没有集成终端电阻。问题来了原来的网络两端各有一个120欧姆电阻总线整体的特性阻抗是匹配的。新增设备虽然没接终端电阻但它的CAN收发器输入端是挂在总线上的等于在总线的中间位置增加了一个电容负载。这个电容虽然不大但在高速下会影响信号边沿导致信号反射。更严重的是新增设备如果是用较长的线缆接入的这段线缆就成了多余的桩反射信号直接在总线上叠加破坏了总线信号完整性。解决方案把新增设备的接入方式改成菊花链即从最近的节点直接串联接入或者缩短接入线缆同时如果新增设备本身不带终端电阻确保它不影响总线两端的电阻匹配。这个案例告诉我们一个道理在CAN网络上添加新节点一定要评估它的电气接口特性不能只看软件兼容性。4.2 案例二整车偶发丢帧但示波器波形正常——共地问题这是一个很经典的表面无异常实则有问题的案例。现象某车型在路试时偶发CAN丢帧频率极低可能开一整天才出现一两次且不可复现。拿到实验室用示波器测波形完全正常即使做电磁兼容测试也没触发问题。初步判断这种偶发问题最折磨人。由于频率太低常规示波器触发抓波形的概率很低只能靠长时间记录和分析。排查过程我建议客户在总线上挂一个CAN记录仪连续记录一周的总线数据并在关键节点仪表、网关、BMS上挂电压监测线。三天后数据回传发现在某次丢帧发生的同时BMS节点处的CAN_H对地电压瞬间出现了约2V的跌落持续了几毫秒后恢复。进一步检查发现BMS控制器的地线端子松动接触阻抗偏大。车辆经过颠簸路面时端子瞬间接触不良导致BMS的CAN收发器地电位相对其他节点发生了跃变。虽然差分信号里CAN_H和CAN_L之间的电压差没有变化但共模电压超出了接收端的容忍范围接收端的CAN收发器输出错误电平导致丢帧。解决方案重新压接地线端子并加涂导电膏。路试一个月后再未出现丢帧。这个案例的启发是排查偶发错误帧时不要只盯着CAN总线本身还要把节点的地线、电源线纳入监控范围。一个毫秒级的电源跌落或地电位跳变就足以让CAN通信出问题而这些问题往往在实验室环境里复现不了。4.3 案例三波特率标称值相同但收发异常——采样点配置的坑这个案例在之前讲采样点时提到过这里展开完整过程。现象两台设备通过CAN直连标称波特率都是500kbps。设备A发送设备B能收到但设备B的CAN错误计数器持续增加一段时间后进入Passive状态报文开始丢失。设备A发送频率越高问题越严重。初步判断如果波特率完全一致且采样点合理不会出现能收到但错误计数增加的情况。这个现象说明收发双方的位时序存在系统偏差但没有大到完全收不到的程度。排查过程用示波器分别抓设备A和设备B发送的波形量出两种波形的实际bit时间。结果发现设备A的bit时间是2.010us设备B接收时的采样点换算下来在约66%的位置远低于推荐的75%~85%。这样一来设备A发送的帧特别是在某些位序列下设备B的采样点采到的电平和发送端不一致触发位错误或填充错误错误计数器缓慢上升。深入检查设备B的CAN控制器初始化代码发现采样点配置寄存器的值算错了——他们把BRP波特率预分频、TSEG1、TSEG2这几个参数填反了位置。虽然最终波特率恰好对了因为BRP和TSEG的乘积刚好凑出了宏定义的500kbps但采样点跑偏了。解决方案重新按照芯片手册的公式计算并改正采样点配置把采样点调到80%附近。设备运行一周错误计数器始终为0。这个案例的教训是配置CAN控制器的位时序时即使波特率最终值正确也一定要验算采样点。很多MCU的CAN驱动代码是从别的项目拷贝过来的换了一块主频不同的芯片后采样点配置就变成了一个隐藏的雷。4.4 案例四总线负载率不高但总线无故瘫痪——单个节点的轰炸现象某控制系统总线负载率只有20%左右但运行一段时间后总线会突然瘫痪几分钟然后自行恢复。瘫痪期间所有节点都收不到报文。初步判断总线负载率不高说明不是过载导致的。瘫痪后能自行恢复说明不是硬件永久损坏。更有可能的是某个节点间歇性地发送大量错误帧触发了故障界定机制。排查过程用CAN记录仪捕获了瘫痪期间的完整报文发现瘫痪前0.5秒开始一个固定ID的节点以极快的频率远高于正常发送周期发送报文且每帧后面都跟着错误帧。错误帧的类型以位错误为主夹杂少量填充错误——这个模式很符合节点本身正常但发送时总线上有干扰源的特征。继续追查这个节点的外围环境发现它旁边有一路24V继电器驱动的电磁阀继电器吸合瞬间会产生强烈的电磁脉冲。虽然CAN线是双绞线但这根双绞线在布线时和24V动力线绑扎在一起长达几十厘米干扰直接耦合到CAN线上。正常情况下这个干扰不足以打坏波形但当这个节点恰好在这个瞬间发送报文时干扰叠加到了信号上导致它自己发送时采样到错误电平触发位错误。更麻烦的是这个节点判断自己发什么都被干扰所以它会重发而每次重发又会遇到继电器噪声于是形成恶性循环。错误计数器一路飙升最终节点进入Bus Off状态停止参与总线通信。等继电器不再吸合总线安静下来节点才慢慢恢复重新进入总线。整个周期大概两三分钟的样子。解决方案将CAN线和24V动力线彻底分离布线同时在这个节点的CAN接口处增加共模电感。整改后连续运行三天错误计数始终为0。这个案例的价值在于总线瘫痪不一定是总线本身的故障有时候是一个倒霉的节点恰好暴露在干扰最强的位置然后它的错误重发行为把自己的错误计数器推到了极限。排查时不要只盯着瘫痪的总线要看瘫痪前哪个节点在猛发错误帧那个节点附近往往藏着干扰源。5. 因子分析与整改方向错误计数器读数的价值很多人不太会利用CAN控制器里的错误计数器其实这玩意儿在排查时非常好用。CAN控制器内部有两个计数器TEC发送错误计数器和REC接收错误计数器。协议规定TEC或REC超过127时节点进入被动错误状态Error PassiveTEC超过255时节点进入总线关闭状态Bus Off。读这个计数值能帮你判断问题出在发送侧还是接收侧。如果TEC持续增长说明这个节点发送报文时老出错是发送方向的问题如果REC持续增长说明这个节点接收报文时老出错问题可能出在发送端、线缆或干扰上。这个信息能帮你缩小排查范围特别在多个节点互连的复杂网络里。还有一种典型场景某节点的TEC和REC同时增长且速度差不多。这种情况往往意味着该节点的物理层收发器或线路有问题它既发不好也收不好。检查重点应放在该节点的CAN收发器芯片供电、CAN_H/CAN_L引脚焊接、共模电感、以及它和连接器的接触质量上。另外通过错误计数器的增长速度可以对问题的严重程度和性质做出初步判断。如果错误计数器涨得慢且偶尔回落大概率是偶发干扰如果涨得快且不回落说明总线状态已经持续恶化多半是硬件问题或配置问题。常见的整改手段归纳一下按优先级排序优先级整改方向措施举例1总线拓扑确认两个终端电阻在位且阻值正确改菊花链布线避免长桩线缩短分支长度2线缆与隔离双绞线远离动力线使用屏蔽层单端接地必要时增加共模电感远距离设备间加强地连接3采样点配置按波特率重新验算采样点控制在75%~85%SJW尽量设为≥1避免复制其他芯片代码时带入旧参数4节点工艺检查连接器端子压接质量、CAN收发器供电纹波、MCU晶振精度和对地电容匹配5软件策略开启CAN控制器的自动重发或关闭重发取决于业务场景合理配置错误中断避免Bus Off后无法自动恢复这里多说一句关闭错误帧自动重发是一个值得斟酌的策略在需要保证实时性的场合自动重发可能导致帧堆积和延迟所以有些项目会显式关闭自动重发改成应用层重试。但自动重发本身是CAN协议的重要容错能力关不关要看业务对实时性和可靠性的具体要求没有放之四海而皆准的答案。排查错误帧问题时建议先保持自动重发开启因为它会让错误帧更明显方便定位。6. 写在最后几个低成本的排查小习惯分享几个我后来一直在用的低成本高收益的操作习惯长期坚持能省下大量排查时间。第一个习惯是任何CAN项目立案后第一件事就是抓一帧总线上的干净波形存档。节点全部正常工作、干扰最低、总线空闲时的CAN_H和CAN_L波形包括波特率、电平幅值、边沿时间全部记录在案。后面出了任何错误帧相关的问题拿出当时的波形对比一分钟就能判断总线的电气基线有没有漂移。这个习惯救了我好几次——有一次客户报波形乱七八糟我调出半年前存档的波形一对比发现其实总线电平从来就是那样只是这次他们的设备软件升级后对波形质量的容忍度变低了。第二个习惯是排查错误帧时永远先把示波器挂在总线上再复现不要先靠猜。示波器的CAN解码功能不一定要买高档型号才有很多中低端示波器都集成了。挂上示波器后耐心等错误帧的出现然后看错误帧前后各1ms的波形。90%的情况下你能直接看到干扰源或波形畸变的位置。第三个习惯是对总线上每一个节点单独测试它发送报文时的错误计数器变化。一台台单独测有问题的节点自然会暴露。这个方法虽然老土但特别有效尤其在多节点网络里可以快速圈定问题范围。第四个习惯是改造完硬件后不要急着撤走分析仪让总线带载运行至少24小时把错误计数器最大值记录下来。如果24小时内错误计数器始终为0或最大值不超过10基本可以认为问题解决了。我给客户做整改验收时都会要求留一个24小时错误计数统计这个数据比任何感觉好多了都有说服力。CAN错误帧的排查说难也难说简单也简单。难的地方在于错误帧只是症状同样的错误帧类型背后可能有完全不同的病因简单的地方在于只要养成分层排查的习惯物理层优先数据链路层其次软件层垫底大多数问题都能在两三天内找到根因。希望这篇文章的案例和思路能给正在被错误帧困扰的同行们一点参考。 CAN总线错误帧排查实战：从五种错误类型到物理层定位
1. 错误帧不是故障是总线在喊救命做CAN总线调试这么多年我最怕听到的一句话不是又丢帧了而是示波器上全是乱七八糟的波形。乱波形背后十有八九是错误帧在刷屏。先说个很多新手容易搞混的概念错误帧不等于故障。CAN协议里内置了五套错误检测机制任何节点发现总线上有不符合规则的信号都会立刻往总线上发一段错误帧来通知所有人——这条消息作废赶紧重发。所以错误帧本质上是CAN总线自我保护的一种机制它像人体免疫系统里的白细胞不是病本身而是身体在报警。真正常见的场景是免疫系统太敏感或者外界刺激太频繁导致总线整天都在喊救命正常消息反而发不出去了。这篇文章不打算讲那种错误帧的五个类型及其定义的教科书内容那个标准协议文档里写得清清楚楚。我想聊的是实际排查中更值钱的东西每一种错误帧出现时总线上到底发生了什么、你该从哪个层面去查、示波器上看到什么波形能快速锁定方向。适合刚接手CAN调试的工程师也适合那些已经被偶发错误帧折磨了几个星期、想换个排查思路的老手。我自己的经验是CAN错误帧的排查八成的坑集中在物理层但八成的排查时间却耗在了软件层。这个比例如果能反过来你的调试效率能提升一大截。下面按我实际排查时的思考路径把五种错误帧挨个拆开讲。2. 五种错误类型逐个拆解触发条件与字节级表现CAN协议定义了五种错误检测机制任何一条报文在发送或接收过程中触犯了其中任何一条都会生成错误帧。别看只有五条它们分属不同检测层级定位方向截然不同。2.1 位错误Bit Error发送者最敏感的自检位错误是五种错误里最微妙的一种。规则很简单发送节点在发送一个显性位逻辑0或隐性位逻辑1时会实时监控总线电平如果发现自己发的是显性但总线上读到的是隐性或者反过来——自己发隐性但读到显性——立刻判定位错误。这里有个关键细节很多人忽略只有在仲裁段和ACK槽发送时发送节点才能容忍这种不一致。仲裁时故意发送隐性位但读到显性位说明有更高优先级的节点在争夺总线这是正常现象不触发错误帧。ACK槽同理发送节点发隐性位但接收节点回显性位表示应答这也是正常的。真正触发位错误报警的场合是数据段、CRC段这些位置出现电平读写不一致。最常见的物理根因有两个一是总线上的信号反射或沿过缓导致发送节点采样到的电平和自己刚发出的不一致二是两个节点波特率偏差过大采样点对不上。2.2 填充错误Stuff Error连续电平的规则破坏者CAN协议规定在SOF到CRC段之间如果出现连续5个相同电平的位发送方必须插入一个反相位的填充位。接收方则在收到连续5个相同电平位后会期待第6位是反相的填充位。如果第6位依然同相直接判定填充错误。为什么要有位填充规则简单说就是为了保证总线上的跳变沿密度。CAN节点恢复时钟依赖总线上的电平跳变如果长时间没有跳变沿节点间的采样时钟会逐渐漂移最终导致采样错误。位填充机制本质上是一种时钟同步的保障手段。这类错误在实际项目里出现频率不算高但它一出现往往意味着更底层的时序问题。我遇到过的案例是某个节点晶振偏差过大波特率实际值和标称值差了好几千ppm导致它在发送长串相同位时填充位的插入时机和其他节点的采样窗错位被误判为填充错误。这种问题光看软件没用得用高精度示波器量实际波特率。2.3 CRC错误CRC Error数据完整性的最后防线CRC循环冗余校验错误是接收节点最容易发现、也最容易误判的一类错误。每个CAN帧的CRC段包含发送节点对前面所有位计算出的15位CRC序列接收节点收到完整帧后用同样的算法重新计算一遍如果结果对不上就判定CRC错误。这里有个容易踩的坑接收节点报CRC错误不代表CRC计算逻辑有问题更多时候是物理层干扰导致帧内容在传输过程中变了。比如总线附近有强电磁干扰把某个显性位打成了隐性位或者信号反射导致某个位的电平在采样点附近抖动采样结果和发送端不一致。CRC错误是果真正的因往往在波形质量上。排查CRC错误时不要一上来就怀疑MCU的CAN控制器坏了或者软件配置错了先拿示波器看波形。重点关注显性/隐性电平幅值是否达标、边沿是否陡峭、有没有振铃和台阶、总线空闲时噪声幅度多大。我见过一个项目CAN_H和CAN_L之间的电容没匹配好导致高速传输时波形出现明显过冲跑几十帧就出一帧CRC错误换了个匹配电容后问题彻底消失。2.4 格式错误Form Error协议帧结构的守护者格式错误针对的是帧格式中那些固定电平的位段比如EOF帧结束的7个隐性位、CRC段的定界符、ACK定界符等。这些位置的位电平是协议写死的如果接收节点在这些位置采样到错误电平就会触发格式错误。格式错误里有个很典型的场景是EOF段End of Frame帧结束段。正常帧结束是7个隐性位如果第7位之前出现显性电平接收节点就会报格式错误。这个显性电平是谁拉低的多半是某个节点在帧还没结束时抢着发消息而这种抢发行为通常是因为它对帧结束位置的判断提前了。什么情况下会判断提前最常见的是波特率不匹配。节点A的波特率比节点B快A会认为帧已经结束开始发下一帧的SOF这个SOF的显性电平在B看来恰好落在EOF段里于是B报格式错误同时A可能也会因为仲裁失败报位错误。所以格式错误频繁出现时先检查各节点的实际波特率和采样点配置大概率能发现问题。2.5 应答错误Ack Error孤独发送者的呐喊应答错误的机制特别有意思。每个CAN帧的ACK槽发送节点会发送一个隐性位任何正确接收到该帧的节点需要在这个位置拉一个显性位来表示我收到了。如果发送节点在ACK槽采样到的仍是隐性位——也就是说没有任何节点应答它——就会判定应答错误。应答错误出现时最先要查的是总线上到底有几个节点这个发送节点是不是孤零零地挂在一条没有其他节点或者其他节点都处于静默状态的总线上这里有个新手常犯的误区往总线上接一个USBCAN盒子打开软件发送报文然后发现软件一直报无应答或ACK错误。原因很简单USBCAN只有发送节点这一个角色没有其他节点接收自然没人应答。但还有一种隐蔽情况发送节点和接收节点的波特率偏差过大接收节点虽然能收到部分位但CRC校验失败按协议规定CRC错误的接收节点不会发送ACK应答。于是发送节点看到的是——自己发出去的消息没人认领——报Ack Error。这种场景里Ack Error只是表象根因是波特率偏差别搞混了。3. 从物理层到链路层错误帧排查的分层思维排查错误帧最大的忌讳是东一榔头西一棒子。我的习惯是分层排查先物理层再数据链路层最后才是软件应用层。这个顺序不是随便定的而是因为物理层的故障占比最高而且如果不先排除物理层问题数据链路层和软件层排查出来的结论往往是不可靠的。3.1 物理层三板斧终端电阻、共地、线缆质量先看终端电阻。CAN总线规范要求线缆两端各接一个120欧姆终端电阻作用是吸收信号反射。如果缺了其中一个或者电阻值偏差太大总线上的信号会出现振铃和过冲轻则降低抗干扰能力重则直接产生位错误和CRC错误。测量终端电阻的办法很简单在总线断电状态下用万用表从任意一个节点处测量CAN_H和CAN_L之间的电阻。正常的总线架构下两个120欧姆并联实际测量值应该在60欧姆左右。如果测出来是120欧姆说明只有一端接了电阻如果测出来是无穷大说明两端都漏接了电阻。再说共地。CAN总线虽然是差分信号理论上可以容忍一定的共模电压差但CAN收发器的共模输入范围是有限的通常在-12V到12V之间具体看型号。当两个节点的地电位差过大时即使差分信号正常共模电压也会超出收发器的承受范围导致信号无法正确识别。我在现场排查过一个典型案例一个设备间相距两百多米的CAN总线偶尔出现错误帧但频率不高大概每分钟一两帧。用示波器挂在总线上看波形完全正常。后来量了两个设备之间的地电位差发现高达3.8V已经接近收发器共模范围的极限。原因是一个设备的地线电阻偏大负载一启动地电位就往上飘。解决方案是在两个设备之间加一条粗的地线错误帧直接清零。最后看线缆。CAN总线推荐使用双绞线而且绞距要均匀。如果用的是平行线或者在某个位置把双绞线破开了一段这段线缆相当于一个天线既容易引入干扰也容易向外辐射。另外要注意线缆的远离原则动力线、高频信号线要和CAN总线保持足够距离交叉时尽量垂直交叉避免长距离平行走线。3.2 波特率与采样点数据链路层最容易被忽略的隐性杀手波特率不匹配是CAN错误帧里最隐蔽的根因之一。注意我说的不一定是不匹配哪怕是标称值完全一样但由于晶振精度不同、CAN控制器分频配置不同实际波特率也会有细微偏差。CAN协议要求所有节点的位时间误差在一定范围内典型值是±0.5%以内具体看波特率和采样点配置。如果两个节点的晶振都是误差±100ppm的普通晶振理论上没问题但如果配置的采样点太靠后或者SJW同步跳转宽度设得太小就可能在某些位序列下触发错误帧。采样点的概念值得展开说说。CAN的一个bit时间分为同步段、传播段、相位缓冲段1和相位缓冲段2。采样点位于相位缓冲段1和相位缓冲段2之间合理的采样点位置通常在75%到85%之间。如果采样点太靠前信号还处于不稳定状态就采样容易采到错误的电平如果太靠后留给相位同步的缓冲余量不够在波特率有偏差时容易采错。我曾经排查过一个极其烦人的问题一辆车上的两个ECU标称波特率都是500kbps程序配置看起来也正常但就是偶尔出现错误帧而且只在特定温度下出现。后来用示波器分别抓两个ECU的波形发现一个采样点在80%另一个实际算下来只有68%虽然都能正常工作但偏差容限很窄。一旦温度变化引起晶振频率偏移误差就超过了容忍范围开始报错误帧。调整一个ECU的采样点配置到80%后问题彻底消失。所以排查错误帧时如果物理层波形看着正常建议用CAN分析仪把总线的实际波特率测出来再查各节点的采样点配置。不要盲目相信代码里的配置值MCU的CAN外设时钟源计算有坑有时候你以为配的是500k实际出来的可能是496k。3.3 CAN分析仪的正确打开方式不只是用来看很多工程师手里有CAN分析仪但用得不充分。分析仪不光是用来发报文、收报文的它还是定位错误帧位置和类型的利器。主流CAN分析仪比如周立功的USBCAN、Vector的CANalyzer或者一些国产工具都支持总线统计功能可以实时显示错误帧的数量和类型。有些高级功能还能记录错误帧发生时刻总线上的其他报文这对排查某个特定报文触发错误帧的问题特别有帮助。我强烈建议排查错误帧时把分析仪挂在总线上开启总线统计同时用示波器探头也挂在CAN_H和CAN_L上打开示波器的CAN解码功能。这样当错误帧发生时你能同时看到错误类型是什么、错误发生的帧是哪个ID、波形上哪一段出现了异常。三路信息一对照定位速度快得惊人。还有一个容易被忽视的小技巧CAN分析仪本身也有接收容错能力。如果分析仪报告的错误帧率和车上ECU错误计数器表现出来的症状对不上很可能是分析仪的采样点配置和车上ECU不一致导致分析仪看到的错误帧和ECU看到的不是同一批。这时候要把分析仪的采样点也调到和ECU一致才能拿到准确的数据。4. 四次实战排查案例从偶发丢帧到系统崩溃理论说得再多不如来几个实际案例直观。下面这几个案例都是我这些年真实处理过的场景各有代表性我把当时的排查链路完整写出来希望能帮大家建立一个可复制的排查思路。4.1 案例一新装节点后系统疯狂报错——终端电阻缺失这个案例特别典型适合作为入门案例。现象客户反馈在原来的CAN网络里新增了一个设备后整个网络开始疯狂报错甚至出现总线瘫痪。拆掉新增设备一切恢复正常。初步判断新增设备带崩了整个总线但具体原因不明。很多人第一反应是新增设备的软件有bug疯狂发错误帧。但仔细一想CAN总线的错误帧机制本身有容错能力单个节点的软件bug理论上不应该让整个总线瘫痪。排查过程先用万用表测量总线两端的终端电阻正常。再测新增设备的CAN接口发现CAN_H和CAN_L之间的阻抗是无穷大——新增设备内部没有集成终端电阻。问题来了原来的网络两端各有一个120欧姆电阻总线整体的特性阻抗是匹配的。新增设备虽然没接终端电阻但它的CAN收发器输入端是挂在总线上的等于在总线的中间位置增加了一个电容负载。这个电容虽然不大但在高速下会影响信号边沿导致信号反射。更严重的是新增设备如果是用较长的线缆接入的这段线缆就成了多余的桩反射信号直接在总线上叠加破坏了总线信号完整性。解决方案把新增设备的接入方式改成菊花链即从最近的节点直接串联接入或者缩短接入线缆同时如果新增设备本身不带终端电阻确保它不影响总线两端的电阻匹配。这个案例告诉我们一个道理在CAN网络上添加新节点一定要评估它的电气接口特性不能只看软件兼容性。4.2 案例二整车偶发丢帧但示波器波形正常——共地问题这是一个很经典的表面无异常实则有问题的案例。现象某车型在路试时偶发CAN丢帧频率极低可能开一整天才出现一两次且不可复现。拿到实验室用示波器测波形完全正常即使做电磁兼容测试也没触发问题。初步判断这种偶发问题最折磨人。由于频率太低常规示波器触发抓波形的概率很低只能靠长时间记录和分析。排查过程我建议客户在总线上挂一个CAN记录仪连续记录一周的总线数据并在关键节点仪表、网关、BMS上挂电压监测线。三天后数据回传发现在某次丢帧发生的同时BMS节点处的CAN_H对地电压瞬间出现了约2V的跌落持续了几毫秒后恢复。进一步检查发现BMS控制器的地线端子松动接触阻抗偏大。车辆经过颠簸路面时端子瞬间接触不良导致BMS的CAN收发器地电位相对其他节点发生了跃变。虽然差分信号里CAN_H和CAN_L之间的电压差没有变化但共模电压超出了接收端的容忍范围接收端的CAN收发器输出错误电平导致丢帧。解决方案重新压接地线端子并加涂导电膏。路试一个月后再未出现丢帧。这个案例的启发是排查偶发错误帧时不要只盯着CAN总线本身还要把节点的地线、电源线纳入监控范围。一个毫秒级的电源跌落或地电位跳变就足以让CAN通信出问题而这些问题往往在实验室环境里复现不了。4.3 案例三波特率标称值相同但收发异常——采样点配置的坑这个案例在之前讲采样点时提到过这里展开完整过程。现象两台设备通过CAN直连标称波特率都是500kbps。设备A发送设备B能收到但设备B的CAN错误计数器持续增加一段时间后进入Passive状态报文开始丢失。设备A发送频率越高问题越严重。初步判断如果波特率完全一致且采样点合理不会出现能收到但错误计数增加的情况。这个现象说明收发双方的位时序存在系统偏差但没有大到完全收不到的程度。排查过程用示波器分别抓设备A和设备B发送的波形量出两种波形的实际bit时间。结果发现设备A的bit时间是2.010us设备B接收时的采样点换算下来在约66%的位置远低于推荐的75%~85%。这样一来设备A发送的帧特别是在某些位序列下设备B的采样点采到的电平和发送端不一致触发位错误或填充错误错误计数器缓慢上升。深入检查设备B的CAN控制器初始化代码发现采样点配置寄存器的值算错了——他们把BRP波特率预分频、TSEG1、TSEG2这几个参数填反了位置。虽然最终波特率恰好对了因为BRP和TSEG的乘积刚好凑出了宏定义的500kbps但采样点跑偏了。解决方案重新按照芯片手册的公式计算并改正采样点配置把采样点调到80%附近。设备运行一周错误计数器始终为0。这个案例的教训是配置CAN控制器的位时序时即使波特率最终值正确也一定要验算采样点。很多MCU的CAN驱动代码是从别的项目拷贝过来的换了一块主频不同的芯片后采样点配置就变成了一个隐藏的雷。4.4 案例四总线负载率不高但总线无故瘫痪——单个节点的轰炸现象某控制系统总线负载率只有20%左右但运行一段时间后总线会突然瘫痪几分钟然后自行恢复。瘫痪期间所有节点都收不到报文。初步判断总线负载率不高说明不是过载导致的。瘫痪后能自行恢复说明不是硬件永久损坏。更有可能的是某个节点间歇性地发送大量错误帧触发了故障界定机制。排查过程用CAN记录仪捕获了瘫痪期间的完整报文发现瘫痪前0.5秒开始一个固定ID的节点以极快的频率远高于正常发送周期发送报文且每帧后面都跟着错误帧。错误帧的类型以位错误为主夹杂少量填充错误——这个模式很符合节点本身正常但发送时总线上有干扰源的特征。继续追查这个节点的外围环境发现它旁边有一路24V继电器驱动的电磁阀继电器吸合瞬间会产生强烈的电磁脉冲。虽然CAN线是双绞线但这根双绞线在布线时和24V动力线绑扎在一起长达几十厘米干扰直接耦合到CAN线上。正常情况下这个干扰不足以打坏波形但当这个节点恰好在这个瞬间发送报文时干扰叠加到了信号上导致它自己发送时采样到错误电平触发位错误。更麻烦的是这个节点判断自己发什么都被干扰所以它会重发而每次重发又会遇到继电器噪声于是形成恶性循环。错误计数器一路飙升最终节点进入Bus Off状态停止参与总线通信。等继电器不再吸合总线安静下来节点才慢慢恢复重新进入总线。整个周期大概两三分钟的样子。解决方案将CAN线和24V动力线彻底分离布线同时在这个节点的CAN接口处增加共模电感。整改后连续运行三天错误计数始终为0。这个案例的价值在于总线瘫痪不一定是总线本身的故障有时候是一个倒霉的节点恰好暴露在干扰最强的位置然后它的错误重发行为把自己的错误计数器推到了极限。排查时不要只盯着瘫痪的总线要看瘫痪前哪个节点在猛发错误帧那个节点附近往往藏着干扰源。5. 因子分析与整改方向错误计数器读数的价值很多人不太会利用CAN控制器里的错误计数器其实这玩意儿在排查时非常好用。CAN控制器内部有两个计数器TEC发送错误计数器和REC接收错误计数器。协议规定TEC或REC超过127时节点进入被动错误状态Error PassiveTEC超过255时节点进入总线关闭状态Bus Off。读这个计数值能帮你判断问题出在发送侧还是接收侧。如果TEC持续增长说明这个节点发送报文时老出错是发送方向的问题如果REC持续增长说明这个节点接收报文时老出错问题可能出在发送端、线缆或干扰上。这个信息能帮你缩小排查范围特别在多个节点互连的复杂网络里。还有一种典型场景某节点的TEC和REC同时增长且速度差不多。这种情况往往意味着该节点的物理层收发器或线路有问题它既发不好也收不好。检查重点应放在该节点的CAN收发器芯片供电、CAN_H/CAN_L引脚焊接、共模电感、以及它和连接器的接触质量上。另外通过错误计数器的增长速度可以对问题的严重程度和性质做出初步判断。如果错误计数器涨得慢且偶尔回落大概率是偶发干扰如果涨得快且不回落说明总线状态已经持续恶化多半是硬件问题或配置问题。常见的整改手段归纳一下按优先级排序优先级整改方向措施举例1总线拓扑确认两个终端电阻在位且阻值正确改菊花链布线避免长桩线缩短分支长度2线缆与隔离双绞线远离动力线使用屏蔽层单端接地必要时增加共模电感远距离设备间加强地连接3采样点配置按波特率重新验算采样点控制在75%~85%SJW尽量设为≥1避免复制其他芯片代码时带入旧参数4节点工艺检查连接器端子压接质量、CAN收发器供电纹波、MCU晶振精度和对地电容匹配5软件策略开启CAN控制器的自动重发或关闭重发取决于业务场景合理配置错误中断避免Bus Off后无法自动恢复这里多说一句关闭错误帧自动重发是一个值得斟酌的策略在需要保证实时性的场合自动重发可能导致帧堆积和延迟所以有些项目会显式关闭自动重发改成应用层重试。但自动重发本身是CAN协议的重要容错能力关不关要看业务对实时性和可靠性的具体要求没有放之四海而皆准的答案。排查错误帧问题时建议先保持自动重发开启因为它会让错误帧更明显方便定位。6. 写在最后几个低成本的排查小习惯分享几个我后来一直在用的低成本高收益的操作习惯长期坚持能省下大量排查时间。第一个习惯是任何CAN项目立案后第一件事就是抓一帧总线上的干净波形存档。节点全部正常工作、干扰最低、总线空闲时的CAN_H和CAN_L波形包括波特率、电平幅值、边沿时间全部记录在案。后面出了任何错误帧相关的问题拿出当时的波形对比一分钟就能判断总线的电气基线有没有漂移。这个习惯救了我好几次——有一次客户报波形乱七八糟我调出半年前存档的波形一对比发现其实总线电平从来就是那样只是这次他们的设备软件升级后对波形质量的容忍度变低了。第二个习惯是排查错误帧时永远先把示波器挂在总线上再复现不要先靠猜。示波器的CAN解码功能不一定要买高档型号才有很多中低端示波器都集成了。挂上示波器后耐心等错误帧的出现然后看错误帧前后各1ms的波形。90%的情况下你能直接看到干扰源或波形畸变的位置。第三个习惯是对总线上每一个节点单独测试它发送报文时的错误计数器变化。一台台单独测有问题的节点自然会暴露。这个方法虽然老土但特别有效尤其在多节点网络里可以快速圈定问题范围。第四个习惯是改造完硬件后不要急着撤走分析仪让总线带载运行至少24小时把错误计数器最大值记录下来。如果24小时内错误计数器始终为0或最大值不超过10基本可以认为问题解决了。我给客户做整改验收时都会要求留一个24小时错误计数统计这个数据比任何感觉好多了都有说服力。CAN错误帧的排查说难也难说简单也简单。难的地方在于错误帧只是症状同样的错误帧类型背后可能有完全不同的病因简单的地方在于只要养成分层排查的习惯物理层优先数据链路层其次软件层垫底大多数问题都能在两三天内找到根因。希望这篇文章的案例和思路能给正在被错误帧困扰的同行们一点参考。