很多调试CAN的人都会遇到这样一个扎心的场景：驱动代码写完了，SPI读写也正常，但调用发送函数之后，数据就是出不去。翻开调试界面一看，MCP2515的三个发送邮箱全部被占满，发送请求位一直拉高；再读错误寄存器，总线错误标志赫然在列。我之前调试MCP2515驱动时就在这里卡了很长时间，后来把CAN协议栈、错误状态机、硬件接线全部理了一遍，才彻底搞明白问题出在哪。这篇文章就把CAN发送和接收失败的常见原因、排查顺序和解决手段一次讲透，尤其是“发送邮箱占满+总线错误”这个组合，我会拆到寄存器级别去分析。
1. 问题复现与第一印象
1.1 三个发送邮箱全被占满，到底说明了什么
MCP2515内部有3个独立的发送缓冲器，也就是我们常说的TXB0、TXB1、TXB2。每次发送数据，本质上是把报文写到其中一个缓冲器，将TXBnCTRL寄存器的TXREQ位置1，然后硬件自动把缓冲器里的报文移位输出到CAN总线上。发送完成后，硬件会清掉TXREQ位，并置位CANINTF里面对应的发送中断标志。
如果你的程序已经把三个邮箱都写满了，而且TXREQ位一直不回落，那就是一个非常明确的信号：MCP2515尝试把报文发出去，但始终没有成功完成“发送”，所以邮箱被一直占着。硬件不会自动丢弃报文，也不会超时回收邮箱，除非你手动用CANCTRL的ABAT位中止发送，否则这三个邮箱会一直锁死。
这种“邮箱占满”的现象，最常见的两个方向：一是总线上根本没有其他节点回应，导致发送节点反复重发错误帧；二是你配置的波特率、采样点等参数和总线不匹配，报文上去就是错的，接收端压根不认。这两个方向对应的是完全不同的排查路径，后面我会分开讲。
1.2 读寄存器读到的“总线错误”是什么
很多人第一次看到“总线错误”四个字会被吓住，以为芯片挂了。其实CAN控制器不会轻易挂，它只是把总线上发生的异常记录在错误寄存器里。MCP2515里有一个专门的EFLG错误标志寄存器（地址0x2D），里面每一位都对应一种错误状态：
| 位 | 标志名 | 含义 |
|---|---|---|
| bit7 | RX1OVR | 接收缓冲器1溢出 |
| bit6 | RX0OVR | 接收缓冲器0溢出 |
| bit5 | TXBO | 总线关闭 |
| bit4 | TXEP | 发送错误被动 |
| bit3 | RXEP | 接收错误被动 |
| bit2 | TXWAR | 发送错误警告 |
| bit1 | RXWAR | 接收错误警告 |
| bit0 | EWARN | 错误警告 |
如果你在调试界面里看到的是TXBO（总线关闭），那说明TEC发送错误计数器已经超过了255，控制器进入了离线状态。MCP2515在这时候会认为自己“和总线彻底失联”，所有发送都会失败，三个邮箱自然全被占满。很多人在这里反复读寄存器，发现错误标志清不掉，就是因为没有理解CAN错误状态机的恢复机制——不是写0就能清掉的，要等总线连续出现128次11位隐性空闲位，硬件才会自动从Bus-Off恢复。
2. CAN底层机制决定成败：发送失败的本质
2.1 发送一个CAN帧，硬件层到底要发生什么
要搞懂发送失败，先得把CAN帧的发送过程完整走一遍。当一个CAN节点准备发送报文时，它先监听总线是否空闲。总线空闲时，节点输出起始帧SOF（一个显性位），然后依次移出仲裁段、控制段、数据段、CRC段，最后是ACK段和EOF结束位。
这里最关键的是ACK段。CAN协议规定：发送节点在ACK槽位释放总线，自身只输出一个隐性位；总线上任何其他节点只要正确接收了该帧，就会在ACK槽上强制输出一个显性位来回应。发送节点必须在ACK槽采样到这个显性位，才算“发送成功”。采样不到，说明总线上一台接收设备都没有，或者接收设备没有正确解析这个帧，发送节点就会立即发出错误帧，然后重发一次。
很多人的MCP2515调试环境是“单节点自测”——只有一块开发板，板上一个MCP2515加一个CAN收发器，没有接任何其他节点。这种情况下，你发出去的帧永远不会有人回ACK，发送永远失败，TEC错误计数器不断累加，直到进入Bus-Off状态。这是所有“邮箱占满+总线错误”案例里最普遍、也最容易忽略的原因。
2.2 为什么“没人接收”也会导致发送失败
有个很常见的认知误区：发CAN报文只要把数据写到总线就行，收不收是别人家的事。实际上在CAN协议里，ACK不是可选项，而是发送成功判断的硬条件。你可以把它类比成寄快递：你把包裹交给快递员，快递员提着包裹走了，这不算完；要等收件人签收，快递系统里才会显示“已签收”。CAN的ACK就是那个“签收回执”。
所以你单独拿一块MCP2515板子接上总线，示波器可能看到波形确实有，但控制器的发送中断就是不来，邮箱就是不放，因为硬件一直认为自己“没送达”。我见过不少人在这时候反复检查SPI时序、检查中断配置，折腾一整天，最后接上另一个CAN节点或者一台USBCAN分析仪，问题当场消失。
2.3 错误帧、错误计数器与总线关闭的连锁反应
当发送失败触发重发，CAN控制器会同时做两件事：发送一个6位显性位的错误帧（Error Frame），并让TEC发送错误计数加8。错误帧是显性优先的，它会强占总线，导致其他节点也被干扰。如果此时总线上有另一个正常节点，它会因为收到错误帧而回复自己的错误帧，双方互相干扰，总线就开始恶性循环。
TEC超过127时，节点从“错误主动”降级为“错误被动”；TEC继续超过255，节点进入“总线关闭”状态。进入Bus-Off后，MCP2515会把发送输出引脚释放为隐性，相当于物理上把自己从总线上摘下来。这时候你再发送任何报文，都只是在本地缓冲器里打转，三个邮箱占满是必然结果。
错误帧这个概念也解释了一个现象：为什么你接上示波器看总线波形，看到一连串“乱七八糟”的信号。那就是节点在不断地发错误帧。很多新手以为是自己代码写错了，其实是节点在“自救”，它在告诉总线：这里有错误，我要重发。
3. MCP2515驱动的系统性排查路径
3.1 先别急着改代码，收一下硬件的基本盘
MCP2515是SPI接口的CAN控制器，但它本身不直接接总线，中间必须有一个CAN收发器，比如TJA1050、SN65HVD230、PCA82C250这些。控制器把差分电平的收发工作交给收发器去做。我排查的时候，第一步永远是看这部分：
- CANH和CANL是否接反。接反之后，节点发出的显性位在线路上是反的，其他节点肯定不认。
- 终端电阻是否接了。标准做法是总线两端各接一个120Ω电阻。如果你只有两个节点，一头一个120Ω；如果你只有一个节点，至少也得接一个120Ω终端电阻。没有终端电阻，总线信号反射会很严重，尤其波特率高的时候，波形直接畸变。
- 收发器供电是否正常。比如TJA1050的VCC需要5V，有些小板子用3.3V供电，收发器工作点不对，RXD输出波形畸变，控制器收到的全是错误。
我建议你先用一张纸把硬件链路画出来：MCU — SPI — MCP2515 — TXD/RXD — 收发器 — CANH/CANL — 总线。逐个环节打勾确认，这一步不过关，后面全是白费。
3.2 第二步：确认SPI通信和寄存器访问正常
MCP2515用SPI通信，最容易出问题的是SPI模式配置错。MCP2515要求SPI Mode 0,0（CPOL=0，CPHA=0），也就是时钟空闲为低，数据在第一个边沿采样。很多STM32的HAL库代码里默认配置的是Mode 0，但如果你是从别的工程复制过来的，有可能还留着Mode 3或者Mode 1，那读出来的寄存器全是0xFF或者0x00，你在上面分析半天没有任何意义。
建议上电之后先读一次CANSTAT寄存器（地址0x0E）。复位后正常情况下它应该等于0x80，即处于配置模式。如果读出来是0xFF，SPI通信大概率有问题；如果读出来是0x00，说明芯片可能没正常上电或没有起振。
另外注意SPI时钟频率。MCP2515的数据手册标注SPI时钟最高10MHz，实际应用中我建议不要超过5MHz，尤其是飞线调试的时候。SPI线长了、时钟高了，很容易出现“时好时坏”的诡异问题，寄存器偶尔写错一位，驱动表现就是各种随机失败。
读取寄存器时还有一个细节：MCP2515的读指令是0x03，后面跟寄存器地址，然后时钟继续走，芯片在下一个字节周期把数据放在SO线上。写指令是0x02。很多人用STM32的HAL_SPI_TransmitReceive来读寄存器，只发了两个字节（指令+地址），没给第三个字节的时钟，数据根本读不出来。这种低级错误很常见，但排查起来非常浪费时间。
3.3 第三步：检查波特率配置，这个坑最多
波特率是CAN调试里最典型的“雷区”。MCP2515有3个寄存器专门配置波特率：CNF1、CNF2、CNF3。它们共同决定了一个位的分段：同步段、传播段、相位缓冲段1、相位缓冲段2。用通俗的话讲，就是“一个位里各段时间怎么切”。
MCP2515的时间基准来自外部晶振，比如8MHz。它内部有预分频器，先分出一个一个的时间量子TQ，然后一个位由若干个TQ组成。波特率计算公式：
波特率 = 晶振频率 / (BRP + 1) / (1 + PROPSEG + PHSEG1 + PHSEG2 + 1)这里BRP是预分频值，后面的1是同步段固定占1个TQ，最后的1是相位缓冲段2至少为1个TQ。举个例子：8MHz晶振，想要125kbps波特率，BRP设为3，即4分频，得到TQ为0.5us；一个位时间等于8us，也就是16个TQ，四个段加起来凑成16，就能实现。
但这里有个很容易翻车的地方：两端波特率数值一样，不代表配置一样。比如你这边125kbps配置出来的采样点在80%，另一端正好是60%，在长线、高负载、信号质量差的情况下，可能就收不到。我个人的习惯是采样点取75%左右，不要低于70%，否则抗干扰能力会很差。这个在CANopen和J1939这些协议栈的参数表里都能看到参考值。
常规波特率对应的参数我整理了一个参考表（8MHz晶振环境）：
| 波特率 | BRP | PROPSEG | PHSEG1 | PHSEG2 | SJW | 采样点 |
|---|---|---|---|---|---|---|
| 1Mbps | 0 | 3 | 4 | 4 | 1 | 75% |
| 500kbps | 0 | 7 | 4 | 4 | 1 | 75% |
| 250kbps | 1 | 7 | 4 | 4 | 1 | 75% |
| 125kbps | 3 | 7 | 4 | 4 | 1 | 75% |
需要说明的是，这个表只是其中一种可行配置，不是唯一答案。不同晶振频率、不同总线长度、不同节点数，最优参数会变。调试的时候一定要用示波器或逻辑分析仪抓波形，看显性位宽度对不对，别只看代码里的波特率变量。
3.4 第四步：用回环模式做最小功能验证
当你怀疑硬件、SPI、波特率，但又不确定问题出在哪时，MCP2515有一个非常好用的调试利器——回环模式（Loopback Mode）。在这个模式下，芯片的发送输出不经过收发器，内部直接“甩回”接收路径。你发的报文可以自己收到，不需要任何外部节点。
回环模式的设置值在CANCTRL寄存器的REQOP位：
| REQOP[2:0] | 模式 |
|---|---|
| 000 | 正常模式 |
| 001 | 睡眠模式 |
| 010 | 回环模式 |
| 011 | 仅监听模式 |
| 100 | 配置模式 |
| 111 | 仅监听模式 |
注意MCP2515里回环模式是010，这和其他一些CAN控制器不太一样，我见过有人拿ST的bxCAN习惯往里填001，结果进的是睡眠模式。
回环模式下如果发送成功、接收中断正常触发，说明MCP2515的SPI通信、寄存器配置、发送邮箱逻辑本身都是好的，问题基本锁定在物理层或者总线侧。如果回环模式下都发不出去，那就要回头查SPI和寄存器配置了。
4. 全场景原因清单：CAN发送/接收失败速查表
4.1 发送失败的原因清单
我把实际调试中遇到过的发送失败原因全部列出来，按从物理层到应用层的顺序排：
| 原因分类 | 具体表现 | 排查方向 |
|---|---|---|
| 总线无ACK回应 | 邮箱占满，TEC持续增加 | 接第二个节点或USBCAN分析仪，确认有人回ACK |
| 终端电阻缺失或不匹配 | 信号反射，偶发发送失败 | 两端各接120Ω，或至少一端接入 |
| CANH/CANL接反 | 所有报文发不出，错误帧连续 | 万用表确认接线颜色和收发器引脚 |
| 波特率不匹配 | 发送端显示发送失败，接收端收不到 | 示波器测量位宽，对照计算配置 |
| 采样点位置不对 | 近距离正常，远距离或高低温失灵 | 调整CNF2/CNF3分段，采样点靠后 |
| SPI配置错误 | 寄存器读写异常，模式进不去 | 检查SPI Mode 0,0和时钟频率 |
| CAN收发器故障 | 芯片正常，但TXD/RXD波形异常 | 万用表、示波器测收发器输入输出 |
| 总线被错误帧堵塞 | 总有其他节点持续发送错误帧 | 逐个断开节点，排查错误源头 |
| 晶振不起振 | 芯片完全无响应 | 示波器测OSC1/OSC2引脚 |
| ID仲裁一直失败 | 同一节点很多，小ID报文抢占 | 调小本节点ID或使用不同ID范围 |
最后一条要展开说一下：CAN总线仲裁是靠ID从高到低逐位比对，显性位（逻辑0）优先于隐性位（逻辑1），所以ID数值越小，仲裁优先级越高。如果你设备挂在一条繁忙的总线上，又用了0x7FF这种很大的标准ID，那么只要总线上有别的节点在发，你几乎永远是输家。驱动代码怎么看都没问题，但报文就是发不出去，原因全在“排队排不上”。
4.2 接收失败的原因清单
接收失败没有发送邮箱占满那么显眼，但同样让人抓狂。常见情况是另一端明明发了，你这边中断什么都没发生。我整理了几个典型方向：
| 原因分类 | 具体表现 | 排查方向 |
|---|---|---|
| 验收滤波器配置错误 | 报文在总线上，但节点不产生接收中断 | 复位后默认接收所有报文，确认是否改了RXF/RXM |
| ID格式不一致 | 发送端发扩展帧，接收端只用标准帧 | 检查SIDH/SIDL/EID配置，MCP2515的IDE位 |
| 接收缓冲器溢出 | RX0OVR或RX1OVR置位，新报文进不来 | 及时读走RXB0/RXB1数据，并清除溢出标志 |
| 中断标志未清 | 接收中断只触发一次，之后不再进 | 读寄存器后务必写0清除CANINTF对应位 |
| 波特率不匹配 | 接收端看不到任何报文 | 回收发端配合抓波形确认 |
| 总线负载过高 | 报文被错误帧冲掉 | 用CAN分析软件看总线负载率和错误帧计数 |
| 发送端和接收端采样点不一致 | 偶发丢包，长线测试更明显 | 使用相同波特率和同步参数配置 |
验收滤波这块特别想多说一句。MCP2515的RXB0和RXB1各有自己的验收屏蔽寄存器RXM0/RXM1，以及验收滤波寄存器RXF0/RXF1等。复位后这些寄存器的默认状态其实是“接收所有报文”，这也是新手刚开始能收到数据的原因。但如果你中途配置了滤波器，ID写错一位，报文就被静默丢弃了——看起来和“总线没数据”一模一样。排查时先把滤波器全部关掉，确认能收到，再逐步缩小过滤范围。
4.3 从热搜词看新手常踩的坑
“CAN初始化失败”“CAN波特率”“错误帧”这几个词在嵌入式社区里出现频率特别高，说明大部分人的问题都集中在初始化阶段。初始化失败九成出在两点：一是配置模式没进成功，寄存器还停留在配置模式就急着发数据；二是退出配置模式后没有验证是否真的切回正常模式。
MCP2515进入和退出配置模式都要“请求-确认”两步：往CANCTRL写入REQOP，然后轮询CANSTAT的OPMOD字段，直到它显示当前模式已经切换成功。很多人只写了请求，没等确认，紧接着就操作发送，结果芯片还在配置模式，发送邮箱的行为完全不符合预期。这种问题用一句话就能总结：硬件初始化是异步的，必须等状态到位。
5. 实操实录：一个“三个邮箱全满”问题的完整排查
5.1 排查过程还原
我接到一个开发者的求助，现象和你标题里写的一模一样：MCP2515三个发送邮箱全占满，读EFLG寄存器能看到TXBO总线关闭标志。他手里只有一块板子，没有第二节点，总线悬空。
我让他先做三件事：
第一，读取CANSTAT确认芯片当前模式。结果读出来是0x80，配置模式，说明芯片活着，SPI通信没问题。
第二，读取TEC发送错误计数。结果0xFF，255封顶，说明已经进入总线关闭状态。
第三，我把他的发送使能代码检查了一遍，发现他把TXREQ置位后，用了一个超时等待循环去等发送中断标志。结果超时时间设的50毫秒，但MCP2515在总线关闭状态下每次重发都要等总线恢复条件，50毫秒根本等不到。
到这里，根因基本锁定：这是一个没有对端节点、总线悬空的单节点调试环境。他发出去的帧永远不会有人回ACK，MCP2515反复重发、错误计数飙升，最终总线关闭。
5.2 找到根因并解决
我给的解决方案是分三步走：
第一步，物理上增加对端。最省事的做法是用USBCAN分析仪接到总线上，软件配置成侦听模式即可。没有USBCAN的话，用另一块开发板也行，总之必须有一个能回ACK的节点。
第二步，如果只有一块板子，就改用回环模式验证逻辑。把CANCTRL的REQOP设为010，发送数据，看能否在RXB0里收到自己发的报文。能收到，说明芯片和配置都没问题，问题纯粹出在“单节点无ACK”上。
第三步，恢复正常模式后，把总线接好，终端电阻接上，再重新初始化。TEC一旦清零，总线关闭标志自动恢复，邮箱就能正常释放了。
这里有一个被很多人忽略的操作细节：从总线关闭恢复之后，你原先写在三个邮箱里的报文，MCP2515不会帮你“自动重发”，TXREQ位依然是置位状态。你得手动把TXBnCTRL清零，把邮箱释放掉，再重新写报文。否则你会发现恢复之后，邮箱还是占满的，误以为问题还在。
5.3 收尾优化建议
问题解决之后，我又在他的驱动代码里补了两个保护机制，这个对长期稳定运行很有价值：
第一个是发送超时清零。发送请求置位后，用轮询方式等待TXREQ自动清零，但加上超时判断。超时后主动读EFLG，如果看到TXBO或者TEC超过127，就执行CANCTRL的ABAT中止发送，把所有邮箱清掉，重新初始化，避免死锁。
第二个是发送前查总线状态。在调用发送函数前，读取EFLG，如果发现发送错误被动或者总线关闭，先不急着发，先做恢复流程。这个保护看着简单，但能避免很多现场设备“卡死重启”的尴尬。
顺手再提一个和驱动关系不大的优化：设计CAN报文ID时，别把发送节点的ID设得太小。正常情况下，ID越小优先级越高，如果你设备里的心跳报文ID是0x001，而它又特别频繁地往外发，整条总线上其他节点都别想说话了。CAN总线仲裁机制不会让你发不出去，但会让别人发不出去，这和“发送失败”一样是事故。
6. 几个踩坑之后留下的心得
调试CAN和调试UART、I2C最大的不同在于，CAN是一个“多节点共识”协议，单机状态下你没法验证任何东西。很多驱动问题并不是驱动本身的逻辑错，而是整个通信环境不具备“发送成功”的条件。这个问题想明白了，大半的CAN调试难题都能解开。
我再分享一个判断技巧：当MCP2515发送失败时，不要只盯着发送邮箱，一定要读一遍EFLG、TEC、REC三个寄存器。它们会告诉你芯片当前的“健康状态”到底怎么样。TEC和REC都在0到127之间，说明节点状态还健康，问题更多在总线侧；TEC超过127，说明节点已经错误被动，发送能力开始受限；TEC超过255，基本可以断定是物理层出了问题，比如没接对端、接反总线、波特率错乱、总线短路。
还有一个我后来养成的习惯：每次调试CAN驱动，先写一个“单板自检固件”，功能只有一个——上电自动进入回环模式，自己发自己收，并且通过LED指示结果。这个固件只要能跑通，说明MCP2515芯片、SPI、驱动框架都是好的。之后再去写正常模式的收发逻辑，一旦出了问题，你就可以放心大胆地把锅甩给物理层和总线环境，而不是浪费时间在芯片和驱动上。这个做法帮我省下了很多无意义的排查时间，也算是我在CAN调试这条路上最有用的经验之一。
