做嵌入式这些年CAN总线是我接触最多的现场总线。说实话CAN通信出问题真正稀奇古怪的原因占比很低绝大多数翻来覆去就是那几类终端电阻不对、采样点配置不合适、错误帧处理不当、物理层信号劣化、多节点联调时引入的连带问题。这篇文章就是把我在多个项目里遇到过的、也帮别人排查过的高频问题整理成一份速记清单每个问题都给出现象、原理、判断方法和处理手段。适合刚接触CAN的嵌入式工程师也适合那些被“偶尔通信失败”折磨的人参考。下文不是教科书是实战笔记。1. 终端电阻的坑为什么总线“通而不稳”十有八九是它1.1 终端电阻到底在干什么很多人对120欧终端电阻的理解停留在“CAN总线上要接120欧电阻”这句话上但遇到具体问题就懵了。其实终端电阻解决的是信号反射问题。CAN的物理层是差分信号总线线缆的特征阻抗大约是120欧如果线缆末端不接匹配电阻信号传到末端会发生反射反射波叠加在原信号上就会造成波形畸变、振铃严重时直接误码。这也是为什么车位短、波特率低的时候少接一个终端电阻可能也能跑但一旦距离拉长、波特率提高问题就暴露了。我调试过不少现场现象是“低速能通信高速丢帧”最后查下来就是漏了一个终端电阻。1.2 装几个、装在哪不是每个节点都装最常见的误解是“每个节点都加120欧”这是错的。标准做法是物理总线的最远两端各加一个120欧电阻。注意这里说的是“物理最远”不是原理图上看起来最远而是线缆实际走向的最远端。如果多个节点是菊花链连接终端电阻应该放在链的两端节点上。如果每个节点都加总线等效电阻会变成多个120欧并联比如3个节点都加等效电阻就只有40欧驱动力会被拉低显性电平幅值不足接收端采样裕量变小。我见过最离谱的是12个节点全加了120欧等效10欧整个网络几乎瘫痪。判断方法很简单断电后在任意节点处量CANH和CANL之间的电阻。正常应该是约60欧因为两个120欧并联。如果量到120欧说明只有一端接了如果量到远小于60欧说明接多了或者线缆短路。这里有个细节量的时候最好把节点控制器也断电因为有些收发器芯片在上电状态下内部阻抗会“污染”测量结果。1.3 设备内置电阻引起的隐性误判很多USB转CAN分析仪、开发板、评估板上都自带终端电阻有的带跳线/拨码开关有的默认焊死。这就导致一个很尴尬的场景你以为没加终端电阻实际某台设备内部已经接了一个120欧你再在总线末端加一个就出现了“三个终端”的局面。我建议拿到任何CAN硬件第一件事就是查清楚它的终端电阻默认状态。很多现场的“CAN通信不稳定、延迟高、波形振铃”最后查出来是某台设备内置终端电阻导致阻抗不匹配。排查的时候不要只看外接电阻要把所有节点的终端情况列一张表逐个确认。1.4 短线场景的另一面终端电阻加多了反而出振铃与“漏接”相对的另一个坑是“短距离接双终端”。当总线长度很短小于1米时信号反射影响本来就小如果还严格在两端加两个120欧收发器的驱动电流有一大半消耗在电阻上显性差分电压可能降到接近阈值。某些MCU开发板上CAN收发器驱动能力偏弱就会出现“示波器看波形正常但某些节点收不到”的怪象。处理办法短线、少节点场景可以只在一端加120欧甚至不加也能工作但这不是标准做法只是调试阶段的临时手段。量产设计还是要按规范来否则换线材、加节点后就有隐患。2. 波特率、采样点与位定时很多“对不上”的根源2.1 一次位时间是怎么切分的CAN总线上每一位信号的时长叫“位时间”它被切成四段同步段SYNC_SEG、传播段PROP_SEG、相位缓冲段1PHASE_SEG1、相位缓冲段2PHASE_SEG2。每个段由整数个时间量子Tq组成Tq由CAN控制器时钟分频得到。采样点就是接收端真正读取电平值的位置一般设计在相位缓冲段1和相位缓冲段2的交界处。为什么不能像UART那样在位的中间采样因为CAN是总线仲裁型的多个节点同时发送时位边沿会实时调整采样点位置需要兼顾“等足够久、让信号稳定”和“留出缓冲、容忍相位误差”两个方向。采样点太靠前远端信号的边沿还没稳定就被采了太靠后万一某节点时钟偏快下一位边沿已经逼近了。行业经验是采样点放在75%到87.5%之间经典值80%左右。2.2 采样点计算的完整实例以某MCU的CAN外设为例APB时钟40MHz目标波特率500kbpsBRP波特率预分频设为4那么Tq 4 / 40MHz 0.1us。一位时间 1/500kbps 2us也就是20个Tq。取SYNC_SEG 1 TqTSEG1 16 TqTSEG2 3 Tq总计20 Tq。采样点 (1 16) / 20 85%。实际波特率 40MHz / (4 × (1 16 3)) 500kbps。这个配置就很经典。很多人配置寄存器时随手填BS113、BS22结果算出来采样点大约83%看起来还行但实际波特率可能已经偏了。问题就在这里即使波特率误差不大采样点偏移也会压缩相位缓冲余量。我在一个项目里遇到过两个节点标称都是500k一个采样点75%一个85%距离一长、温度一变就开始丢帧。所以同一网络里每个节点的采样点最好统一误差控制在百分之几以内。2.3 时钟误差预算为什么“标称相同”仍不能通信CAN允许各节点时钟存在误差但不允许无限大。接收节点要靠SJW同步跳转宽度来容忍相位误差SJW一般设为1到4 Tq。两个节点的晶振误差若是±1.5%和±0.5%最坏情况相对误差约2%。在高速CAN500k以上下这个误差可能消耗掉大部分相位缓冲余量。我在实际调试中最常见的错误是用内部RC振荡器跑CAN尤其波特率高于250k时内部RC的温漂会让网络时好时坏。这个不是配置问题是时钟源精度问题。经验值是125k以下内部RC还能凑合250k以上建议外部晶振或者有校准机制的时钟源。2.4 位定时相关的快速自查点遇到完全不通但硬件看起来没问题的情况按这个顺序查两端实际波特率是否一致采样点是否都落在75%-87.5%区间SJW是否设得太小建议至少1 Tq高速率下2 Tq更稳两个节点的时钟误差是否过大BRP和BS1/BS2组合后实际波特率和目标值是否偏差超过1%。任何一项不满足都可能表现为“偶尔能通、时好时坏”而不是完全不通这也是最折磨人的地方。3. 错误帧与Bus Off从现象反推根因的排查法3.1 错误类型速记每类错误指向一个大方向CAN的错误帧不是一个笼统概念细分下来有五种每种对应的排查方向差别很大。位错误Bit Error发送节点发出显性位却收到隐性回读说明总线被其他节点拉低了或总线短路。多见于收发器损坏、总线对地短路。填充错误Stuff Error连续6个相同电平说明波特率不匹配或强干扰把电平翻转丢了。CRC错误数据经过干扰后校验不一致常见于线缆过长、屏蔽不好、靠近大功率设备。形式错误Form Error固定位段电平不对通常也是干扰或波特率不匹配。ACK错误发送节点在应答槽没有收到显性位说白了就是总线上没有其他节点在正常接收。很多初学者拿到错误帧统计看到“Error Frame”就慌其实大方向一锁定问题面就窄了。有一次客户说“总线疯狂报错”我让他把错误类型截图发过来结果是清一色的ACK错误——原来他用了USB转CAN分析仪但分析仪的接收功能被关掉了总线上除了被测节点没有别人应答。3.2 错误计数器与状态迁移什么时候会变成Bus Off每个CAN节点内部有一个发送错误计数器和接收错误计数器。规则不复杂接收出错加1发送出错加8成功收发时计数器递减。当任一计数器达到128节点进入“被动错误”状态只能接收、不能主动发送发送前还要等8个隐性位。当发送错误计数器达到256节点进入Bus Off彻底断开总线不再参与通信。Bus Off的恢复不是立刻的。控制器需要在总线上检测到128次“11位连续隐性位”即128个总线空闲序列才能回到主动状态。这意味着如果总线上有另一个节点在持续发送错误帧Bus Off的节点可能永远等不到足够长的空闲恢复时间被无限拉长。现场表现为“节点死掉一段时间后又活过来活过来又死掉”。这个机制很多人不知道以为是程序bug其实是错误风暴导致的Bus Off反复。3.3 单节点调试的假故障回环模式与正常模式的区别调试单个节点时如果用的是正常模式而不是回环Loopback模式发送报文就会因为没有节点应答而产生ACK错误。这不是硬件坏了是CAN仲裁机制的必然行为。很多MCU的CAN外设支持Loopback模式内部自发自收不看总线应答。调试单板时用回环模式验证代码联调时切回正常模式。我在一个项目中看到有人在正常模式下跑单板测试把发送错误计数器打到了200多处于被动错误状态然后又怀疑硬件折腾了两天。其实只要明白ACK错误机制一分钟就能解释清楚。3.4 Bus Off恢复的软件处理Bus Off之后除了等控制器自动恢复软件上还可以主动干预。常见做法是开Bus Off中断在中断里重新初始化CAN外设快速恢复到主动状态。但要注意如果总线上有持续错误帧立即恢复只会再次进入Bus Off形成“反复重启发错误帧”的恶性循环。更稳妥的做法是Bus Off后延迟一段时间比如100ms到1s再恢复让总线上的错误风暴先平息。4. 物理层波形看起来“有波形”不代表能通信4.1 显性/隐性的电平标准用示波器看CAN总线波形是最直接的物理层判断手段。标准情况下隐性位时CANH和CANL都是2.5V左右差分电压约0V显性位时CANH抬升到约3.5VCANL拉低到约1.5V差分电压约2V。看波形时我习惯先用差分方式看CANH减CANL这样最干净。如果只有单端探头那就分别看两个信号但要注意共模偏移。我遇到过一个现场CANH对地有4.2V、CANL对地有0.3V差分看起来是3.9V很大但共模已经严重偏了个别收发器直接罢工。差分探头或两通道相减才能还原真实信号。4.2 常见异常波形形态显性幅值不足差分电压只有1V左右。可能是终端电阻过多、线缆过长、节点驱动能力弱。量一下终端等效电阻就能确认。边沿变缓上升沿/下降沿像山坡一样。说明总线电容过大线缆太长或分支太多。此时要考虑降低波特率或者换低电容线缆。振铃显性到隐性跳变后有明显的回摆振荡。基本可以确定是终端电阻缺失或阻抗不匹配。隐性电平漂移隐性位不是2.5V而是3V或1.5V。常见于共地问题总线两端的设备地电位不一致导致共模偏移。4.3 线缆长度、节点数量与总线电容的经验值CAN总线的长度和波特率是有换算关系的固定经验1Mbps下建议最长不超过40米500k不超过100米125k大约500米50k以下才有机会到1000米以上。节点数量受收发器输入阻抗和总线电容影响常规收发器建议不超过32个节点。超过这个数要么用低电容收发器要么增加网关中继。我调试过一个36节点的低速CAN网络波特率只有50k按理说没问题但总有零星CRC错误。后来用示波器一量总线上边沿已经严重变缓显性位宽度被压缩采样点附近的电压裕量极小。这不是波特率问题是节点数带来的电容问题后来拆成两段用中继器隔离症状消失。4.4 测量探头和接地方式小心把好波形量成坏波形示波器探头的地夹如果接得不好会引入额外噪声甚至把总线波形量成一团毛刺。测量时最好用差分探头或者用两通道A-B模式。普通的10:1探头地夹线太长本身就像一个天线贴近CAN线时容易拾取干扰。另外要注意示波器的地是否和被测系统共地如果示波器插在三相插座上而系统是隔离供电地环路可能把某些保护二极管打开。5. 多节点、休眠唤醒与低功耗联调的高频翻车点5.1 节点增多之后问题为什么会冒出来单点调试一切正常两点联调偶尔丢帧多点联调直接瘫痪——这种“系统集成阶段才暴露”的问题多半不是软件变化而是物理层参数变了。每增加一个节点总线电容增加几十pF等效输入阻抗降低信号边沿变缓。原来采样点余量就紧张的网络加第三个节点时直接崩。处理这类问题我的建议是先看采样点是否还有余量比如采样点是不是卡在78%这种边缘值再看终端电阻是否在节点增加后被人为改动最后看总线拓扑是否因为走线原因变成了星型结构。星型拓扑在CAN里是大忌分支过长会产生反射但很多现场布线时根本没注意。5.2 休眠唤醒机制的常见坑CAN收发器进入待机/睡眠模式后通常靠总线活动唤醒。看起来简单实际联调时坑很多。最常见的是“某个节点不进入休眠”原因往往是程序进入低功耗前没有把TXD引脚拉高而是默认拉低。收发器在TXD低电平时会把总线拉成显性总线一直有显性电平其他节点检测到总线活动永远等不到休眠条件。第二个常见坑是“唤不醒”。有些收发器唤醒需要检测到显性电平持续特定时间如果唤醒报文只有一个极短的显性脉冲可能唤醒不了。解决办法是唤醒报文按协议要求发送足够宽度的显性电平。第三个坑和错误帧有关某节点处于Bus Off或被动错误状态时唤醒报文会被它当成错误帧忽略表现为“其他节点都醒了就它醒不了”。先清错再唤醒。5.3 低功耗模式下的总线电平测量调试低功耗CAN网络时不要只用万用表量总线电压判断“有没有通信”。因为万用表的平均值会把瞬态活动平滑掉看起来像没有信号。我习惯用示波器触发方式抓总线波形确认是否有唤醒脉冲。另外还要注意在总线进入隐性状态后节点内部的偏置电阻会建立约2.5V的共模电平。如果某个节点漏电或者损坏总线可能停在某个非2.5V的电位上网络整体无法进入隐性表现为“整个网络无法唤醒”。6. 高频问题的快速排查流程与速查表6.1 三类症状对应的排查主线CAN问题从现象上分三类排查思路完全不同第一类“完全不通”。优先查物理连接终端电阻是否在60欧左右、CANH/CANL是否接反这是常见的低级错误、总线对地/对电源是否短路、节点是否处于Bus Off。这类问题用万用表就能解决八成。第二类“时好时坏、丢帧”。优先看错误帧类型和波形CRC错误大于填充错误时查干扰和地填充错误多时查波特率和采样点显性幅值不足时查终端电阻和节点数量边沿变缓时查线缆和分支。这类问题需要示波器参与。第三类“单点通信正常联调不行”。优先查采样点一致性、终端电阻分布、拓扑结构以及各节点的时钟误差。这类问题最容易让人怀疑芯片本身但绝大多数时候是网络参数不统一。6.2 推荐检查顺序与工具用法我的现场排查顺序固定是万用表量终端电阻和对地电压 → 示波器看波形幅值、边沿、振铃 → 总线分析仪统计错误帧类型和计数 → 逐步摘除疑似节点做隔离测试。这里有个容易忽略的细节用USB转CAN分析仪统计错误帧时如果分析仪本身没有终端电阻或者误接了终端电阻统计结果都可能失真。先确认分析仪的终端配置和被接入节点的物理状态是已知的再开始统计。还有一个实用技巧隔离测试时不要一次性把所有节点都摘掉而是二分法。把网络从中点断开先测左半段再测右半段很快就能定位到具体节点或线缆段。这个方法在排查“偶尔CRC错误”时比逐个节点拔插高效得多。6.3 高频问题速查表现象可能原因快速验证方法处理手段完全无通信终端电阻缺失/错误、接线反、Bus Off万用表量60欧、量CANH/CANL对GND修正终端、纠正接线、复位节点时通时不通采样点偏、时钟误差大、干扰示波器看波形裕量、错误帧类型调采样点到80%左右、换晶振ACK错误风暴单节点在正常模式发送、无接收节点看错误计数、确认对端在线用回环模式/接入正常节点CRC错误多干扰、线缆过长、共地不良示波器抓毛刺、量共模电压加强屏蔽、缩短线缆、改善地连接显性幅值不足终端过多、驱动弱、节点过多量终端等效电阻、看差分幅值调整终端、加中继总线无法进入隐性某节点拉低总线、收发器损坏全部断电量总线电压再逐个上电隔离损坏节点入不了休眠TXD未拉高、总线一直显性看TXD状态、量总线电平修正低功耗前GPIO状态无法唤醒唤醒报文太短、节点处于错误状态示波器抓唤醒脉冲、看错误计数加宽唤醒显性、先恢复节点这份表是我每次去现场都会先过一遍的东西。里面每一条都是我踩过或者帮别人排查过的真实方向。CAN总线之所以让人觉得“玄学”往往不是原理有多深而是排查没有章法。把物理层、数据链路层的参数固定下来再按现象分类问题其实是可复现、可定位的。最后再分享一个我在多轮项目里养成的习惯每次联调前先花十分钟把所有节点的波特率参数表、采样点数值、终端电阻状态、时钟源类型拉通对一遍。这十分钟省下的时间远比很多人在示波器前盲猜几个小时来得多。CAN总线的问题多数不是秘密只是分布在不同节点上等你去对齐而已。
