STM32F103 CAN通信标准库实战：从初始化到双机收发与故障排查

做嵌入式这些年，回过头看，STM32F103的CAN通信确实是很多人遇到的第一个"中等难度"外设：串口很快调通了，I2C、SPI也能照葫芦画瓢跑起来，一上CAN就开始冒各种奇奇怪怪的问题。CAN本身不难，难的是资料太乱——网上能找到的教程一半是纯寄存器版，一半是HAL库版，真正基于标准外设库、从建工程到双机收发、还把坑点讲透的文章很少。这篇文章就把我这些年用标准库在F103上做CAN通信的完整经验串一遍，从硬件连接、初始化配置、收发测试到中断与过滤器，最后附上几个实际项目中的故障排查记录，代码直接用标准外设库V3.5，可以直接抄。

先说清楚这篇文章适合谁：正在用STM32F103标准库做CAN通信、但卡在"初始化到底该怎么配""为什么回环能通、组网不通""过滤器怎么设才能只收我想要的帧"这些问题上的朋友。如果你已经在用HAL库，也可以对照着看，配置思路完全一致，只是API名字换了。

1. 动手之前的硬准备：硬件电路、工程模板和工具链

1.1 F103的CAN外设到底长什么样

STM32F103的CAN控制器是bxCAN（Basic Extended CAN），它本身不负责电平转换，MCU的CAN控制器引脚输出的是逻辑电平，必须外接CAN收发器芯片，比如TJA1050、MCP2551、SN65HVD230，才能连到CANH和CANL两根差分线上。

大多数F103型号只带一个CAN控制器，也就是CAN1，默认引脚映射在PA11（CAN1_RX）和PA12（CAN1_TX）。只有部分大容量型号像STM32F103ZET6、VET6才同时有CAN1和CAN2。这里有一个非常容易踩的坑：PA11和PA12同时是USB的D-和D+引脚，如果你的板子上USB和CAN共用这两个脚，信号是冲突的，不是这里乱就是那里乱。解决办法是用重映射功能把CAN1挪到PB8（RX）和PB9（TX），后面我会专门再讲这个。

还有一点新手容易忽略：CAN外设挂载在APB1总线上。F103在72MHz主频下，APB1时钟默认是36MHz，这是后面所有波特率计算的基础。如果系统时钟配置变了，APB1不再是36MHz，你按36MHz算出来的波特率全是错的，通信表现就是"两边都发，但谁都收不到"，这种问题最隐蔽。

1.2 收发器选型和电路上三个不能省的点

收发器芯片的选择直接影响调试体验。TJA1050和MCP2551是5V供电，SN65HVD230是3.3V供电。F103的IO逻辑是3.3V，接5V供电的TJA1050时要注意：TXD输入引脚可以直接由3.3V驱动，这个没问题；但RXD输出的高电平接近5V，需要确认MCU对应引脚是不是5V容忍（FT引脚）。PA11和PA12本身是FT引脚，所以直接用没问题。如果你把CAN重映射到PB8/PB9，也要查一下数据手册确认这两个脚是FT，通常也是。

电路上有三个点，我每个项目都会检查一遍：

1. 终端电阻：CAN总线两端各需要1个120Ω电阻。如果你只是两块板子短距离对接，每个板子都带120Ω，那总线等效电阻是60Ω，也能正常工作。但如果以后要扩展节点，尽量用"只有最远端两块板接120Ω"的方式，避免总线负载过大。
2. 共地：两个节点之间除了CANH、CANL，GND一定要连在一起。CAN收发器输出的是差分信号，但收发器本身需要参考地，不共地时经常出现"单独收发都正常，一接上另一个节点就乱码"。
3. 收发器工作模式使能脚：TJA1050有S脚，高电平进入静默模式，只能收不能发；SN65HVD230的RS脚也有类似作用。很多现成模块已经把S脚拉低，但自己画板子时特别容易忘，忘掉的表现就是"能收到数据，但发不出去"。

还有一点关于CAN模块供电：不建议把USB-CAN分析仪或某个CAN模块的电源当作板子的主供电来源。调试时模块和主板共用一个电源没问题，但正式项目里各节点该独立供电就独立供电，电源干扰最能在CAN这种差分总线上引起间歇性故障。

1.3 标准库工程模板的最小化组织方式

标准库工程不需要从零开始。我的做法是直接复制一个之前调通的F103工程模板，然后把CAN需要的文件补进去：stm32f10x_can.c、stm32f10x_gpio.c、stm32f10x_rcc.c，如果要做串口打印调试，再加上stm32f10x_usart.c。如果之前的工程模板还没有stm32f10x_can.c，去标准外设库V3.5的src目录里拷贝，同时把对应头文件的路径加进Include路径。

新工程下载调试时如果遇到DAP下载失败，先检查BOOT0跳线是不是接到了1（正常跑用户程序要接0），以及SWD两个脚是不是被代码复用成了普通IO。我见过有人把PA13/PA14重映射成别的功能，结果下一次就下不进程序了，只能按住复位键抢时间下载。这个跟CAN本身没关系，但新手很容易把两件事混在一起，搞了半天以为是CAN配置问题。

2. 标准库初始化背后：从GPIO到波特率每一步的原理推算

2.1 时钟和GPIO：三个"使能"缺一不可

CAN要跑起来，第一步是打开时钟。CAN1挂在APB1上，所以要开RCC_APB1Periph_CAN1；GPIOA挂在APB2上，要开RCC_APB2Periph_GPIOA；如果用了重映射，还必须开RCC_APB2Periph_AFIO，并且调用重映射函数。这三个使能缺一个，现象都不一样：缺CAN时钟，初始化返回失败；缺GPIO时钟，引脚没反应；缺AFIO时钟，重映射不生效，发出去的数据还是从PA12走。

GPIO的模式选择也容易犹豫。CAN_TX（发送脚）要配成GPIO_Mode_AF_PP，也就是复用推挽输出，因为CAN控制器输出信号要经过GPIO复用功能送到引脚。CAN_RX（接收脚）配成GPIO_Mode_IPU（上拉输入）就行，也有项目用GPIO_Mode_IN_FLOATING浮空输入，实测都行，我更习惯上拉输入，抗干扰好一点。

标准库的代码写出来就是这样的：

GPIO_InitTypeDef GPIO_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_AFIO, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_CAN1, ENABLE); // 如果使用重映射，把CAN1的引脚换到PB8/PB9 // GPIO_PinRemapConfig(GPIO_Remap1_CAN1, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_11; // CAN1_RX GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IPU; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12; // CAN1_TX GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &GPIO_InitStructure);

如果你用重映射，把GPIOA改成GPIOB、引脚改成GPIO_Pin_8和GPIO_Pin_9，再取消那行GPIO_PinRemapConfig的注释。

2.2 CAN初始化结构体：每个字段到底在说什么

CAN初始化结构体CAN_InitTypeDef里有十来个字段，看着多，但真正需要关心的就两类：波特率相关和模式相关。

波特率相关字段是CAN_Prescaler（分频系数）、CAN_BS1、CAN_BS2、CAN_SJW。CAN的每一位（bit）在总线上由若干个时间量子（Tq）组成，典型结构是：

1个SYNC_SEG + BS1段 + BS2段

CAN_SJW是同步跳转宽度，跟波特率无关，一般取1Tq就行。波特率的完整计算公式是：

波特率 = APB1时钟 / (CAN_Prescaler × (1 + CAN_BS1 + CAN_BS2))

这里1 + CAN_BS1 + CAN_BS2就是1位占用的总Tq数。以F103默认的36MHz APB1时钟为例，常用波特率可以这么配：

注意BS1和BS2的可取值范围：BS1的寄存器位宽是4位，实际支持1到16个Tq；BS2的位宽是3位，实际支持1到8个Tq。不要在配置时超过这个范围。

采样点的概念很多人不重视：它表示接收方在1位时间内的哪个时刻采样总线电平。CAN总线布线如果比较长、或者分支多，信号跳变沿会有回波，采样点太靠近位起点容易采到不稳定区域。工业上推荐75%到85%，上表里77.8%就是比较稳的选择。

模式相关字段里，我只在真正需要时才打开这几个：CAN_ABOM自动离线恢复，这个建议打开，后面第五部分会详细说，总线出错导致离线后它能自动恢复；CAN_TXFP是发送优先级控制，置1时按发送请求顺序排队，置0时按报文ID优先级排队，一般项目保持0即可；CAN_NART置1会禁止自动重发，一般不打开，让控制器自动重发更省心。

标准库初始化CAN外设的完整代码：

CAN_InitTypeDef CAN_InitStructure; CAN_InitStructure.CAN_TTCM = DISABLE; // 时间触发通信模式 CAN_InitStructure.CAN_ABOM = ENABLE; // 自动离线管理 CAN_InitStructure.CAN_AWUM = ENABLE; // 自动唤醒模式 CAN_InitStructure.CAN_NART = DISABLE; // 非自动重传模式，关闭 CAN_InitStructure.CAN_RFLM = DISABLE; // 接收FIFO锁定模式，关闭 CAN_InitStructure.CAN_TXFP = DISABLE; // 发送FIFO优先级，按ID优先级 CAN_InitStructure.CAN_Mode = CAN_Mode_LoopBack; // 先配回环模式 CAN_InitStructure.CAN_SJW = CAN_SJW_1tq; CAN_InitStructure.CAN_BS1 = CAN_BS1_13tq; CAN_InitStructure.CAN_BS2 = CAN_BS2_4tq; CAN_InitStructure.CAN_Prescaler = 4; // 36MHz / (4 * 18) = 500kbps CAN_Init(CAN1, &CAN_InitStructure);

很多朋友在这段代码里纠结"CAN_SJW_1tq后面能不能换成数字"，答案是不要换，直接用标准库定义好的宏，宏的值和寄存器字段是对应好的，你自己写个1很可能就错位了。

2.3 过滤器初始化：第一次调试就全收，通了再收窄

CAN控制器本身就带硬件滤波，过滤器的配置逻辑是：一堆报文从总线上过来，先经过过滤器筛选，只有通过筛选的报文才能进接收FIFO，软件才能读到。

第一次调CAN的时候，我强烈建议先配一个"全不过滤"的过滤器，也就是不管收到什么帧都收。这样能先把收发链路验证通，再回来设过滤规则，否则一旦收不到数据，你根本分不清是发送问题还是过滤太严。

全收过滤器的配置如下：

CAN_FilterInitTypeDef CAN_FilterInitStructure; CAN_FilterInitStructure.CAN_FilterNumber = 0; // 使用过滤器0 CAN_FilterInitStructure.CAN_FilterMode = CAN_FilterMode_IdMask; CAN_FilterInitStructure.CAN_FilterScale = CAN_FilterScale_32bit; CAN_FilterInitStructure.CAN_FilterIdHigh = 0x0000; CAN_FilterInitStructure.CAN_FilterIdLow = 0x0000; CAN_FilterInitStructure.CAN_FilterMaskIdHigh = 0x0000; CAN_FilterInitStructure.CAN_FilterMaskIdLow = 0x0000; CAN_FilterInitStructure.CAN_FilterFIFOAssignment = CAN_Filter_FIFO0; CAN_FilterInitStructure.CAN_FilterActivation = ENABLE; CAN_FilterInit(&CAN_FilterInitStructure);

这里的关键是掩码：掩码位为0表示"这一位不关心"，为1才表示"这一位必须和ID寄存器对应位一致"。所以把掩码全配成0，就是所有ID的帧都收。实际工作中我见过有人把这个逻辑记反，配了半天只收得到固定一帧，其他全丢，还以为是总线问题。

3. 收发测试完整流程：环回、双机链路和第一轮故障清单

3.1 先做回环测试：把怀疑范围圈在MCU内部

调试CAN通信，我的顺序永远是先回环（LoopBack）、再点对点（双机）、最后才上多节点。回环模式是CAN控制器内部的逻辑自检：发送的数据不进收发器、不上总线，而是直接从控制器内部绕回到接收邮箱。这个模式下即使板子上根本没接收发器芯片，也能完成"发送->接收"的完整验证。

回环模式只需要把上一节初始化代码里的CAN_Mode_LoopBack配好，然后写个简单的发送函数和一接收检查逻辑。

uint8_t CAN1_SendFrame(uint16_t id, uint8_t *data, uint8_t len) { CanTxMsg TxMessage; uint8_t mailbox; TxMessage.StdId = id; TxMessage.ExtId = 0; TxMessage.IDE = CAN_Id_Standard; // 标准帧 TxMessage.RTR = CAN_RTR_Data; // 数据帧 TxMessage.DLC = len; for (uint8_t i = 0; i < len; i++) { TxMessage.Data[i] = data[i]; } mailbox = CAN_Transmit(CAN1, &TxMessage); if (mailbox == CAN_TxStatus_NoMailBox) { return 1; // 三个发送邮箱都满了，请求失败 } // 等待发送完成，实际项目里建议加超时 while (CAN_TransmitStatus(CAN1, mailbox) != CAN_TxStatus_Ok) { } return 0; }

注意CAN_Transmit的返回值：如果分配到了邮箱，返回邮箱号0、1、2；如果三个发送邮箱全满，返回CAN_TxStatus_NoMailBox。有些老资料会把这个返回值当"是否发送成功"来判断，这是不对的，CAN_Transmit只是把报文提交给硬件去发，真正发完要查CAN_TransmitStatus。

接收端在回环测试里直接轮询FIFO：

CanRxMsg RxMessage; if (CAN_MessagePending(CAN1, CAN_FIFO0) > 0) { CAN_Receive(CAN1, CAN_FIFO0, &RxMessage); // RxMessage.StdId 就是发出去的ID，RxMessage.Data里就是数据 }

回环通过，说明MCU内部的CAN控制器、初始化配置、发送接收流程都是好的。这时候如果后面接上收发器还不通，问题就锁定在外部电路或差分总线上，排查范围一下子小了很多。

3.2 切到Normal模式做真正的双机收发

回环验证通过后，把初始化里的CAN_Mode_LoopBack改成CAN_Mode_Normal，重新上电，然后两套板子接线：

• 板A的CANH接板B的CANH
• 板A的CANL接板B的CANL
• 两块板的GND连一起
• 总线两端各保留一个120Ω终端电阻

发送端代码不用动，接收端用一个最简单的轮询就行。跑起来以后，A板每500ms发一帧，B板收到后通过串口打印ID、长度和几个字节的数据。我第一次在这个环节就遇到个经典问题：回环一切正常，一上总线就收不到。查了半天，发现是收板子的终端电阻没焊，总线波形反射严重。所以后来我调试双机时，第一步永远是拿示波器在CANH和CANL之间看有没有清晰的差分方波，没有方波就先别怀疑代码。

这里再强调一遍共地的问题。两块板子如果各自用独立的开关电源供电，VCC之间不连通，那就必须把GND连起来。CAN收发器内部的比较器是以本地GND为参考的，不共地就等于收发器的参考电平对不上，轻则数据错误，重则直接损伤收发器。

3.3 第一轮收发失败：我通常按这个清单排查

新手在"回环通了、总线不通"这个阶段最容易心态爆炸，因为问题不在代码逻辑里。我的排查顺序是固定的：

这个清单我打印出来贴在工位上，后面几个项目排查问题基本都能命中前四行。

4. 中断接收与多节点过滤：从"能通"到"好用"的进阶细节

4.1 中断接收配置：别把CAN_Bus_Off中断和FIFO中断搞混

轮询接收在验证时够用，但正式项目里谁也不会让CPU死等一个FIFO。CAN的中断接收配置分成两步：第一步使能中断源，第二步配置NVIC优先级。

对FIFO0接收来说，要打开的是CAN_IT_FMP0（FIFO0有报文挂起）。有的朋友会打开CAN_IT_FF0或CAN_IT_FOV0，这俩分别是FIFO0满和FIFO0溢出中断，不是正常接收用的。

NVIC_InitTypeDef NVIC_InitStructure; NVIC_InitStructure.NVIC_IRQChannel = USB_LP_CAN1_RX0_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 2; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure); CAN_ITConfig(CAN1, CAN_IT_FMP0, ENABLE);

中断服务函数名字是固定的，F103标准库里CAN1的FIFO0接收中断向量对应USB_LP_CAN1_RX0_IRQHandler，这个名字不要自己改，改了就链接不到中断向量表上。

void USB_LP_CAN1_RX0_IRQHandler(void) { CanRxMsg RxMessage; if (CAN_GetITStatus(CAN1, CAN_IT_FMP0) != RESET) { CAN_Receive(CAN1, CAN_FIFO0, &RxMessage); // 把RxMessage拷贝到自己的接收缓冲区，置标志位 // 不要在中断里做耗时的串口打印、flash写入等操作 CAN_ClearITPendingBit(CAN1, CAN_IT_FMP0); } }

一个细节：FMP0这种中断标志，在FIFO数据被读走后硬件会硬件清除，但为了代码统一规范，我仍然会调用CAN_ClearITPendingBit，实测不会出问题。

4.2 过滤器实战：精确收一个ID和收一组ID的写法

回环测试通过之后，就可以把过滤器从"全收"改成"只收我想要的"。先看只收标准帧ID=0x123的情况：

CAN_FilterInitStructure.CAN_FilterMode = CAN_FilterMode_IdMask; CAN_FilterInitStructure.CAN_FilterScale = CAN_FilterScale_32bit; CAN_FilterInitStructure.CAN_FilterIdHigh = (0x123 << 5) & 0xFFE0; CAN_FilterInitStructure.CAN_FilterIdLow = 0; CAN_FilterInitStructure.CAN_FilterMaskIdHigh = (0x7FF << 5) & 0xFFE0; CAN_FilterInitStructure.CAN_FilterMaskIdLow = 0;

这里最核心的是左移5位的操作。原因一句话就能说清：在32位过滤器的寄存器里，标准ID的11位被放在了高16位寄存器的bit[15:5]上，所以要把ID左移5位，正好对齐。掩码也一样，0x7FF表示11位全部要匹配，再左移5位对齐到对应位置。

如果只想收一组ID，就借助掩码把不想管的位写成0。比如ID范围0x310到0x31F，也就是高6位固定，低5位可变，掩码高16位写(0x7E0 << 5)，ID高16位写(0x310 << 5)，这样0x310到0x31F就都能进了。这个逻辑用熟了，后面做多节点协议拆分会很舒服。

4.3 多节点共存时最容易忽略的邮箱和优先级问题

F103的CAN有3个发送邮箱和2个接收FIFO，每个FIFO能缓冲3个报文。这意味着发送时连续CAN_Transmit三次以内不会阻塞，但如果你一次突发几十帧，就要做好发送邮箱满的重试逻辑。我见过一个项目在循环里连续发送，不对CAN_TxStatus_NoMailBox做处理，结果偶发丢帧，查了很久才发现是邮箱满了，新报文直接被丢弃。

多节点组网时，CAN的仲裁机制会自动处理总线竞争：ID越小，优先级越高。标准库里默认CAN_TXFP = DISABLE，就是按ID优先级仲裁。如果你希望所有节点按"先到先发"的顺序发，再考虑把CAN_TXFP置1，否则保持默认最稳。

5. 三次实际项目中的"玄学"问题排查全过程

5.1 波特率算得明明对，可就是收不到

有次做双机调试，波特率配500k，两边程序都是从同一份模板改的，理论上不可能不一致，但死活不通。我把代码看了三遍，波特率没算错，过滤器也是全收。后来拿示波器量波形，发现CAN_TX引脚上的位宽跟500k对不上，一个位明显比2微秒宽很多。

顺着这个线索查下去才发现，问题出在时钟源上。那批板子用的是12MHz的外部晶振，但工程模板是按8MHz晶振做的，SystemInit里的倍频配置是基于8MHz算的。实际系统主频根本不是72MHz，APB1自然也不是36MHz，波特率跟着全偏了。

这个坑的教训是：拿到一个工程模板，第一件事别急着写CAN，先确认板子的外部晶振频率和SystemInit的配置是否匹配。用串口打印SystemCoreClock，或者用PA8的MCO功能把系统时钟输出到示波器上看一眼，比什么都管用。CAN波特率这种东西，差1%都可能通信失败，何况是差了那么大。

5.2 回环正常，接上TJA1050就是不通

另一个项目，回环测试一切正常，一旦把CAN_Mode改成Normal，同样代码就是不通。排查第一步检查了收发器供电，5V正常，接线也是对的，CANH接CANH，CANL接CANL。用示波器点CAN_TX引脚，MCU侧波形是有的，但点到TJA1050那一侧的CANH-CANL差分波形，什么也没有。

最后发现问题出在TJA1050的S引脚上。那批板子自作主张把S脚通过10k电阻上拉到5V，等于收发器一直工作在静默模式，只收不发。把S脚直接接地之后，波形立刻出来了。

这类问题极具迷惑性，因为"能收到数据"往往让人误以为收发器完全正常，忘了静默模式是"能收不能发"。如果你用的收发器也有模式选择引脚，上电后用万用表量一下这个脚的电平，确认它处在正常收发模式。

5.3 通信一段时间后偶发掉线，查到最后是bus-off恢复的问题

还有一次是设备长时间运行后偶发掉线，重启后又正常。刚开始怀疑是干扰，因为现场有电机启停，但只要把设备放回实验室，跑一天也没问题。后来我在代码里周期打印CAN的错误寄存器，发现掉线前错误计数器一路飙升，直到进入bus-off状态，之后控制器就完全退出了总线，不再参与通信。

标准库里有个CAN_ABOM字段，全称是自动离线管理（Auto Bus-Off Management）。如果这个字段没打开，CAN控制器进入bus-off后不会自动恢复，必须软件重新初始化CAN外设才能重新上线。打开CAN_ABOM后，控制器会在适当时候自动回到总线，项目最终稳定了下来。

这段经历让我养成了一个习惯：初始化CAN时，CAN_ABOM一定设为ENABLE。同时，代码里加一个周期性的错误状态检查，用CAN_GetFlagStatus(CAN1, CAN_FLAG_BOF)判断是否发生过bus-off，方便现场远程定位问题。

5.4 PA11和PB8之间的重映射选择

前面说过PA11/PA12和USB引脚冲突的问题，单独拿出来再说一次，是因为我确实见过有人在这里绕了很久。现象是：板子同时用了USB虚拟串口和CAN通信，两个功能互相干扰，CAN数据偶尔错，USB也经常枚举失败。这不是芯片bug，而是引脚复用打架了。

正确的做法是启用CAN1重映射，把CAN1_RX挪到PB8、CAN1_TX挪到PB9，同时把GPIO初始化里的GPIOA换成GPIOB，并在初始化前调用GPIO_PinRemapConfig(GPIO_Remap1_CAN1, ENABLE)。还有一个容易漏的点：重映射需要打开AFIO时钟，也就是开头说的RCC_APB2Periph_AFIO。这个时钟忘了开，重映射配置写进去也不会生效。

如果板子上PB8和PB9已经接了其他功能，那就只能重新画板把USB和CAN分开了。用一个USB转串口芯片把调试口和CAN功能剥离开，是更省心的方案。

最后分享一个我从CAN调试中得出的习惯：每次改完配置，只改一个变量，然后回环测试一遍，再上总线测试。这个看起来笨的方法，在排除"玄学"问题时其实最有效率。手边常备USB-CAN分析仪，能把总线上实际跑的ID和数据都抓出来，比在代码里猜快得多。等到项目稳定了，再把波特率表、过滤器配置和错误处理逻辑沉淀成一套标准模板，后面所有产品的CAN通信初始化都能半小时搞定。