STM32F103RE CAN总线收发例程：从回环测试到双机通信

简介面向STM32F103RE开发者的CAN总线通信实战资料包围绕回环自测与双机收发两个例程展开并配套完整的CAN协议文档适合正在学习嵌入式通信或需要快速完成CAN功能验证的工程师与学生。CAN是ISO标准化的串行通信协议凭借多主通信、高可靠性和减少线束等特点在汽车电子、工业自动化、船舶、医疗设备等领域应用广泛资源中把协议背景、帧格式、波特率配置、报文收发以及总线仲裁等要点集中整理还涉及帧结构与错误处理机制便于按需查阅。整个压缩包约9.5MB以rar格式分发内容主要包含可导入工程的例程源码和协议说明资料可直接在板卡上烧录调试。已有609人学习/下载借助回环测试可单独验证CAN底层驱动双机通信例程则展示多节点数据交互流程能够帮助开发者快速上手并缩短项目初期协议排查时间。1. 为什么嵌入式设备间通信最后都绕不开CAN总线做嵌入式开发五年我拆过的板子少说也有几十块从工业网关到车载控制器几乎每一块上面都能看到CAN收发器的身影。原因其实很直接当设备之间需要传的数据量不大、但可靠性要求极高时UART太随意I2C和SPI又受限于距离和主从结构真正能打的就是CAN。这个话题里的stm32f103RE CAN总线收发例程把回环测试和双机通信两条路径都铺好了协议资料也完整刚好可以作为切入CAN协议栈的一块跳板。对于刚接触CAN的工程师这套例程的价值在于不需要一开始就去啃ISO 11898-1协议原文而是先把回环模式跑通确认MCU内部收发链路正常再切换到双机模式做真实总线通信。对于有经验的开发者这份资料里的协议文档可以帮你快速确认帧格式、仲裁机制和位时序的细节省去翻手册的时间。CAN总线本身并不复杂但参数配错、终端电阻缺失、波特率不一致这类问题足以让一个看似简单的双机通信调上半天。这篇文章就按协议基础、外设配置、回环与双机通信、位时序调优、故障排查这条线展开把能直接用的配置和排查方法都放出来。2. CAN协议基础从物理层到数据链路层的关键机制CAN能成为汽车和工业领域的标准协议核心在于它解决了几类共性问题多主通信、实时性、抗干扰能力和错误检测。在动手写代码之前先把这些机制梳理清楚后面配置寄存器时才不会发懵。2.1 CAN的物理层特性差分信号与总线电平CAN的物理层使用的是差分信号CAN_H和CAN_L两条线之间的电压差来决定逻辑电平。显性电平逻辑0对应CAN_H和CAN_L之间的电压差约为2V隐性电平逻辑1时两条线都被偏置到2.5V左右电压差接近0V。正是因为这种差分结构CAN总线在工业环境中有很强的共模干扰抑制能力线缆可以做到几十米甚至上千米。STM32F103RE内部集成的bxCAN外设只是一个控制器它不负责物理层的电平转换所以MCU的CAN_TX和CAN_RX引脚必须外接CAN收发器芯片比如TJA1050或SN65HVD230。收发器的作用就是把控制器输出的逻辑电平转换成CAN_H和CAN_L上的差分信号。在双机通信时总线的两端各需要接入一个120Ω终端电阻用来匹配传输线阻抗、抑制信号反射。实际布线时还需要注意CAN_H和CAN_L应该使用双绞线这样两条线上的共模噪声才能相互抵消。如果现场条件不允许双绞线至少要让两条线紧贴走线避免形成大的环路面积。还有一点容易被忽略CAN收发器的地线必须和MCU共地否则总线上的共模电压会超出收发器的输入范围导致通信异常。2.2 数据帧结构与仲裁机制为什么CAN不会发生数据冲突CAN的报文格式中最常用的是标准数据帧CAN 2.0A它由以下几个字段组成帧起始SOF、仲裁场11位标识符加RTR位、控制场IDE、DLC、数据场0到8字节、CRC场、ACK场和帧结束。仲裁机制是CAN最精妙的设计之一。当多个节点同时向总线发送数据时每个节点会一边发送仲裁场的标识符一边回读总线电平。如果自己发送的是隐性位1但总线上读到的是显性位0说明有其他节点在发送更高优先级的帧当前节点立即停止发送并转为接收状态。标识符的值越小帧的优先级越高全0的帧拥有最高优先级。这也是很多工程师在设计CAN网络时会把最重要的控制帧分配较小ID的原因。例程代码中默认使用0x123作为发送帧ID在测试阶段这个值没太大讲究但真正做产品时标识符的分配需要提前规划避免多个节点的高优先级帧频繁占用总线导致低优先级帧长时间发不出去。2.3 错误检测与故障界定CAN自愈能力的来源CAN协议内置了五种错误检测机制位错误、填充错误、CRC错误、格式错误和应答错误。每个节点内部还有一个错误计数器根据收发过程中的错误情况递增或递减。当某个节点的发送错误计数超过255时它会进入总线关闭Bus-off状态自动与总线隔离不影响其他节点的通信。这个设计保证了单个节点硬件故障时整个CAN网络仍然可以正常工作。但反过来说如果某条总线上反复出现错误帧错误计数器会持续累加节点不断进入恢复和重发状态总线利用率会急剧下降。这就是为什么调试CAN通信时不能只看数据能不能收到还要关注错误计数器的值。例程中的回环测试特意绕过了物理层在控制器内部把输出回接到输入这样可以验证MCU的CAN收发逻辑和寄存器配置是否正确排除硬件故障的干扰。如果在回环模式下数据收发正常但双机通信异常问题基本就锁定在物理层、波特率或者终端电阻上。3. STM32F103RE的bxCAN外设配置从引脚到收发中断STM32F103RE的bxCAN外设挂在APB1总线上时钟频率默认是36MHz。这个外设的特点是拥有三个发送邮箱和两个接收FIFO每个FIFO深度为3也就是最多可以缓存6条接收报文给实时性要求高的应用留出了缓冲空间。3.1 GPIO和CAN外设的初始化代码先看GPIO和CAN外设的初始化部分。PA11和PA12是CAN的默认引脚PA11复用为CAN_RXPA12复用为CAN_TX。#include stm32f1xx_hal.h CAN_HandleTypeDef hcan1; void CAN_GPIO_Init(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_CAN1_CLK_ENABLE(); __HAL_RCC_GPIOA_CLK_ENABLE(); /* CAN_RX: PA11, CAN_TX: PA12 */ GPIO_InitStruct.Pin GPIO_PIN_11 | GPIO_PIN_12; GPIO_InitStruct.Mode GPIO_MODE_AF_PP; /* 复用推挽输出 */ GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); } void CAN_Init(void) { hcan1.Instance CAN1; hcan1.Init.Prescaler 9; /* 波特率 36MHz / (9 * (1 7 6)) 500kbps */ hcan1.Init.Mode CAN_MODE_NORMAL; /* 正常模式改为CAN_MODE_LOOPBACK可用回环 */ hcan1.Init.SyncJumpWidth CAN_SJW_1TQ; hcan1.Init.TimeSeg1 CAN_BS1_7TQ; hcan1.Init.TimeSeg2 CAN_BS2_6TQ; hcan1.Init.TimeTriggeredMode DISABLE; hcan1.Init.AutoBusOff ENABLE; /* 自动退出Bus-off状态 */ hcan1.Init.AutoWakeUp DISABLE; hcan1.Init.AutoRetry ENABLE; /* 发送失败自动重发 */ hcan1.Init.ReceiveFifoLocked DISABLE; hcan1.Init.TransmitFifoPriority DISABLE; if (HAL_CAN_Init(hcan1) ! HAL_OK) { Error_Handler(); } }这段代码里最关键的是Prescaler、TimeSeg1和TimeSeg2三个参数的组合它们直接决定波特率。APB1时钟36MHz分频系数9得到4MHz的CAN时钟一个时间量子TQ就是250ns。再乘以同步段1个TQ加上BS1的7个TQ加上BS2的6个TQ总共14个TQ一个位的时间是3.5μs对应的波特率就是500kbps。AutoRetry这个参数值得单独说一下。当它使能时如果发送失败比如总线仲裁丢失或没有节点应答硬件会自动重新发送报文不需要软件干预。这在总线负载较高时可以提高发送成功率但也会带来一个副作用如果总线上确实没有其他节点在监听发送端会不断重发持续占用总线同时错误计数器不断累加最终触发Bus-off。所以在调试阶段建议先使用回环模式验证配置再切换到正常模式。3.2 滤波器配置CAN的接收滤波器用于过滤不需要的报文减少MCU的中断负载。bxCAN每个FIFO关联一组滤波器工作在标识符掩码模式时可以按位屏蔽不需要关心的位。void CAN_Filter_Init(void) { CAN_FilterTypeDef sFilterConfig {0}; sFilterConfig.FilterBank 0; sFilterConfig.FilterMode CAN_FILTERMODE_IDMASK; /* 掩码模式 */ sFilterConfig.FilterScale CAN_FILTERSCALE_32BIT; /* 32位滤波器 */ sFilterConfig.FilterIdHigh 0x0000; sFilterConfig.FilterIdLow 0x0000; sFilterConfig.FilterMaskIdHigh 0x0000; sFilterConfig.FilterMaskIdLow 0x0000; /* 掩码全0接收所有报文 */ sFilterConfig.FilterFIFOAssignment CAN_RX_FIFO0; sFilterConfig.FilterActivation ENABLE; if (HAL_CAN_ConfigFilter(hcan1, sFilterConfig) ! HAL_OK) { Error_Handler(); } }掩码全0意味着不关心标识符的任何位所有报文都能进入FIFO0。在实际项目中如果只需要接收某几个特定ID的报文可以把FilterIdHigh设为期望的标识符掩码设为要精确匹配的位。比如只接收ID为0x123的标准帧标识符的高16位写入0x0123掩码也写入0x0123而扩展帧相关的位掩码为0。滤波器配置完成后需要调用HAL_CAN_Start(hcan1)启动CAN外设再通过HAL_CAN_ActivateNotification使能接收中断否则收不到数据。3.3 中断优先级和NVIC配置CAN接收中断的优先级需要根据项目的实时性要求来设定。如果CAN报文承载的是控制指令中断优先级应该偏高避免被其他低优先级中断阻塞。void CAN_NVIC_Init(void) { HAL_NVIC_SetPriority(CAN1_RX0_IRQn, 2, 0); HAL_NVIC_EnableIRQ(CAN1_RX0_IRQn); } void CAN1_RX0_IRQHandler(void) { HAL_CAN_IRQHandler(hcan1); }在HAL_CAN_RxFifo0MsgPendingCallback回调函数中处理接收到的报文这是HAL库推荐的做法。需要注意的是中断回调中不要做耗时操作比如浮点运算或者打印日志最多把数据拷贝到全局缓冲区置一个标志位然后在主循环中处理。4. 回环测试与双机通信从内部自检到真实收发回环测试的目的很纯粹验证MCU内部CAN控制器的收发逻辑是否正常。它不需要外部收发器也不需要第二块板子PA11和PA12上的数据在芯片内部就被回接到接收路径上。而双机通信则是真正把数据放到总线上验证物理层连接、终端电阻和波特率匹配。4.1 回环模式验证内部收发通路把初始化代码中的hcan1.Init.Mode CAN_MODE_LOOPBACK然后发送一帧数据在接收中断中检查是否收到相同内容。CAN_TxHeaderTypeDef txHeader; CAN_RxHeaderTypeDef rxHeader; uint8_t txData[8] {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08}; uint8_t rxData[8]; uint32_t mailbox 0; void CAN_Loopback_Test(void) { txHeader.ExtId 0; txHeader.IDE CAN_ID_STD; /* 使用标准帧 */ txHeader.RTR CAN_RTR_DATA; /* 数据帧 */ txHeader.DLC 8; /* 数据长度8字节 */ /* 标准帧ID直接写入StdId */ txHeader.StdId 0x123; /* 发送报文 */ if (HAL_CAN_AddTxMessage(hcan1, txHeader, txData, mailbox) ! HAL_OK) { Error_Handler(); } } void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { if (hcan-Instance CAN1) { HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, rxHeader, rxData); /* 比较rxData和txData内容是否一致 */ } }HAL_CAN_AddTxMessage会把报文放入发送邮箱并立即触发发送。在回环模式下控制器在发送的同时就把数据放进了接收FIFO所以发送完成后会立刻进入接收回调。注意mailbox变量用来记录使用的是哪个发送邮箱通常不需要额外处理但在多报文连续发送时可以通过它确认邮箱是否全部占满。如果回环测试能收到数据说明CAN控制器的时钟配置、滤波器、发送和接收路径都是通的。如果收不到优先检查HAL_CAN_Start是否被调用以及滤波器掩码是否设置为全0。4.2 双机通信的硬件连接与初始化差异双机通信时两块stm32f103RE板子的CAN_H相连、CAN_L相连然后在总线两端各接一个120Ω终端电阻。这个问题几乎每天都有新手踩坑只接一端或者不接终端电阻总线信号反射会导致数据帧的CRC校验失败表现为发送端一直报错、接收端偶尔能收到一帧乱码。双机通信对波特率的要求非常高。CAN协议规定总线网络上所有节点的波特率误差必须在一定范围内否则仲裁机制可能失效低优先级节点永远无法占用总线。使用500kbps波特率时每个节点的时钟误差建议控制在0.5%以内。STM32F103RE的HSE晶振精度一般在20ppm以内完全满足要求但如果使用内部HSI时钟误差会明显偏大不建议在双机通信中使用。两块板子的初始化代码完全一致只是发送和接收逻辑不同。板A发送板B接收这个最简单如果要双向通信每个板子都要注册发送和接收中断。/* 板A发送消息给板B */ const uint8_t data_to_b[8] {H, E, L, L, O, 0x00, 0x00, 0x00}; /* 板B的接收回调 */ void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { uint8_t recv_buf[8]; HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, rxHeader, recv_buf); }双机通信中一个常见问题是板A发送后HAL库返回HAL_CAN_AddTxMessage成功但板B一直收不到。排查思路是先用示波器或逻辑分析仪抓CAN_H和CAN_L引脚上的波形看是否有正常的显性和隐性电平切换。如果没有波形问题大概率在发送端或收发器电路如果有波形但板B收不到用万用表量一下CAN_H和CAN_L之间的电阻正常应该在60Ω左右两个120Ω终端电阻并联如果量到120Ω说明另一端没接终端电阻。4.3 错误计数器与Bus-off状态排查在HAL库中可以通过hcan1.ErrorCode读取最后发生的错误类型但如果要看实时的错误计数器需要直接操作寄存器uint8_t can_tx_err_cnt hcan1.Instance-ESR CAN_ESR_TEC; /* 发送错误计数 */ uint8_t can_rx_err_cnt (hcan1.Instance-ESR 8) CAN_ESR_REC; /* 接收错误计数 */当发送错误计数超过127时节点进入错误被动状态此时它发送的报文必须在ACK时隙等待更长时间会降低通信效率。超过255则进入Bus-off节点完全脱离总线。如果板A在双机通信中频繁进入Bus-off错误计数器会给出方向性的提示TEC持续增加说明发送路径有问题可能是板B不在线、终端电阻缺失或波特率不匹配REC持续增加说明接收路径有问题可能是总线信号质量差或自身波特率配置不合理。5. 波特率计算与位时序调优从公式到寄存器配置CAN的波特率不是随便设的它的本质是把一个位时间划分为若干时间量子再通过调整同步段、传播段和相位缓冲段使得采样点位于位时间的稳定区域。STM32F103RE的位时间结构是同步段固定1个TQ加上BS1和BS2总共可以配置为多个TQ。5.1 位时间结构理解与采样点选择一个位时间由四个部分组成同步段SYNC_SEG固定为1个TQ用于节点间的时钟同步传播段PTS用于补偿总线上信号传播延迟和物理收发器的延迟相位缓冲段1PS1和相位缓冲段2PS2用于吸收不同节点时钟的相位误差。STM32F103RE把PTS和PS1合并为BS1对应代码里的TimeSeg1。采样点的位置在BS1结束、BS2开始的地方。对于500kbps及以上的波特率采样点通常在75%到85%之间比较理想。前面例子里的配置SyncSeg 1TQ BS1 7TQ BS2 6TQ总位时间14TQ采样点在 (17)/14 57.1%。这个值偏低对总线较短的测试环境问题不大但总线长度超过10米时传播延迟会让信号到达时间更晚采样点需要往后移比如配置为BS1 9TQ、BS2 4TQ采样点变为 (19)/14 71.4%。不同波特率常用配置如下APB1时钟目标波特率预分频BS1BS2采样点36MHz1Mbps47TQ6TQ57.1%36MHz500kbps97TQ6TQ57.1%36MHz250kbps187TQ6TQ57.1%36MHz125kbps367TQ6TQ57.1%36MHz500kbps89TQ4TQ71.4%把APB1时钟换成8MHz、16MHz或72MHz时需要重新计算预分频系数。公式是波特率 APB1时钟 / (预分频 × (1 BS1 BS2))。注意BS1和BS2的取值单位是TQ而不是直接写时间。5.2 位时序重同步SJW参数的实际作用SJW同步跳转宽度决定了节点在一个位时间内最多能调整多少个TQ来补偿相位误差。它只在检测到边沿相位误差时才起作用典型场景是总线负载变化导致某些节点时钟漂移。SJW取值过大不会提高通信质量反而会牺牲位时间的稳定性因为它允许采样点跳变幅度过大。对于晶体振荡器驱动的STM32F103RESJW设为1TQ或2TQ足够。只有在使用内部RC振荡器或者跨节点波特率误差较大时才需要增大SJW。hcan1.Init.SyncJumpWidth CAN_SJW_2TQ;上面的配置表示SJW为2TQ。如果总线上某个节点的时钟误差达到2%而你的位时间总长度是14TQSJW1TQ时最多能补偿1/14 ≈ 7.1%的误差理论上够用。但误差是累积的多个节点叠加后可能不够此时适当增大SJW能提升容错能力代价是信号完整性略有下降。5.3 用逻辑分析仪验证波特率配置没有CAN协议分析仪时逻辑分析仪也能凑合用。抓取CAN_TX引脚在发送空闲帧或者数据帧时的波形测量显性位的持续时间可以反推出实际波特率。比如抓到最窄的显性脉冲宽度为2μs对应1位时间波特率就是1/2μs 500kbps。但CAN帧里存在位填充机制连续5个相同电平后会插入一个反相填充位所以最窄的脉冲不一定总是1位宽度需要多看几个帧再下结论。如果手头有一块USB-CAN适配器配合PCAN-View或SocketCAN工具可以直接解析帧ID和数据。这里提供一段Linux下用SocketCAN验证节点通信的脚本# 加载CAN驱动并启动can0接口 sudo ip link set can0 type can bitrate 500000 sudo ip link set can0 up # 查看can0接口状态和错误计数 ip -details link show can0 # 接收CAN报文 candump can0 # 发送一帧ID为0x123的数据帧 cansend can0 123#0102030405060708ip -details link show can0输出里能看到state和restart-ms等信息。如果接口状态变成bus-off说明总线错误太多可以手动执行sudo ip link set can0 down再up来恢复。cansend发送的数据格式是ID#十六进制字节can0 123#...表示使用标准帧ID 0x123发送8字节数据CPU是stm32的板子在逻辑分析仪上应该能抓到完全相同的ID和数据。USBCAN适配器和stm32f103RE节点对接时确认双方使用相同的帧格式标准帧还是扩展帧否则适配器能发但MCU侧可能因为IDE位不匹配而把所有报文都过滤掉。6. 收尾技巧用回环中断计数与ERR引脚快速定位硬件还是软件问题开发和维护CAN节点时一个很实用的技巧是利用MCU的CAN错误中断和错误计数器把硬件问题和软件问题快速分开。很多工程师在双机通信失败时第一反应是改代码但实际统计下来约一半的CAN通信故障出在物理层收发器虚焊、终端电阻缺失、CAN_H和CAN_L接反、地线没共地。而CAN控制器本身提供了足够多的诊断手段不需要一开始就上示波器。具体做法是在初始化时使能CAN错误中断并在错误回调中记录错误状态到全局变量方便在主循环中查询volatile uint8_t can_bus_error_flag 0; volatile uint8_t can_busoff_flag 0; void HAL_CAN_ErrorCallback(CAN_HandleTypeDef *hcan) { uint32_t error_code HAL_CAN_GetError(hcan); if (error_code HAL_CAN_ERROR_ACK) { /* 发送无应答说明总线上没有其他节点或终端电阻缺失 */ can_bus_error_flag 1; } if (error_code HAL_CAN_ERROR_BOF) { /* 总线关闭节点已自动与总线脱离 */ can_busoff_flag 1; } }判断逻辑很简单发送后如果触发ACK错误中断说明帧已经发到总线上但没有节点应答。此时先检查对端节点是否上电、是否处于正常模式以及总线两端是否有120Ω终端电阻。回环模式下不会出现ACK错误因为报文在内部就被接收了只有切换为正常模式后ACK错误才有意义。按这个思路双机通信失败时先看错误标志位。提示不要在一次通信失败后就单独看HAL_CAN_ERROR_ACK它只能说明发送瞬间总线上没有应答节点排查时要结合发送错误计数一起看。TEC持续在96到127之间徘徊通常是总线信号质量差比如线缆过长或分支过多TEC快速冲到255基本可以确认对端没在线或终端电阻缺失。还有一个经验值可以参考。CAN总线的线缆长度与波特率直接相关500kbps时总线长度不建议超过100米降到250kbps可以延伸到250米左右125kbps则可以到500米。例程默认的500kbps在实验室内没问题如果要在车间现场部署先把波特率降到250kbps或125kbps再配合双绞线和终端电阻通信稳定性会明显好于直接沿用默认参数。设备正常工作的表现是错误计数器维持在0附近总线上传输的都是有效数据帧candump里看不到任何(ERROR)标记。把这套例程吃透之后CAN的调试思路就清晰了回环模式把控制器本身的问题隔离出去双机模式验证物理层错误计数器和中断把故障定位到具体环节位时序参数则用来在传输距离和实时性之间做权衡。后续不管是换用GD32、AT32还是其他带CAN外设的MCU这套排查逻辑和参数计算方法是通用的。本文还有配套的精品资源点击获取