1. 从零开始：为什么CAN回环测试是嵌入式开发的“第一课”

如果你刚开始接触STM32的CAN总线，或者用CubeMX和HAL库做项目时，面对CAN通信心里没底，那这篇文章就是为你准备的。我见过不少新手，包括当年的我自己，一上来就想让两块板子互相通信，结果连最基本的发送都调不通，对着示波器和逻辑分析仪抓耳挠腮，浪费大量时间。后来我才明白，在真正连接外部CAN网络之前，有一个极其重要、能帮你快速建立信心的步骤——CAN回环测试。

简单来说，回环测试就是让STM32芯片自己跟自己“说话”。芯片内部的CAN控制器会把要发送的报文，不经过物理的CAN收发器（也就是那个TJA1050之类的芯片），直接“绕个圈”送回到自己的接收缓冲区。这听起来有点自娱自乐，但它能帮你排除掉至少80%的初期问题：硬件连接对不对？收发器有没有坏？终端电阻接没接？这些外部因素统统被绕过了。你只需要关注最核心的部分：CubeMX的配置是否正确，HAL库的API调用是否得当，以及你的代码逻辑有没有问题。

所以，这个“简单的CAN回环测试”，恰恰是理解CAN通信栈、验证软件配置的黄金起点。它能让你在几分钟内就看到通信成功的迹象，这种即时反馈对学习信心的建立至关重要。今天，我就以最常用的STM32F103系列为例，带你手把手走一遍从CubeMX配置到代码编写、再到验证的完整流程。你会发现，用HAL库操作CAN，比想象中要简单得多。

2. CubeMX工程配置：细节决定成败

打开STM32CubeMX，新建一个工程，选择你的目标芯片（比如STM32F103C8T6）。我们的目标是配置CAN工作在回环模式，并让它能自发自收。

2.1 时钟树与引脚分配：基础中的基础

在开始配置CAN之前，先确保芯片的时钟源正确。对于F103，通常使用外部高速晶振（HSE）。在RCC配置中，将High Speed Clock设置为Crystal/Ceramic Resonator。然后进入Clock Configuration标签页，将系统时钟（SYSCLK）通过PLL倍频到72MHz（这是F103的常用最高频率）。CAN外设的时钟（APB1 Peripheral Clocks）来源于APB1总线，这里会自动计算，确保它不超过36MHz（F103的APB1上限）。

接下来是关键一步：找到Connectivity下的CAN1。点击它，你会看到模式选择。这里有两个至关重要的模式：

• Normal：正常模式，报文通过TX/RX引脚发送到外部收发器。
• Loopback：回环模式，报文在内部循环，不依赖外部引脚。

我们的测试选择Loopback模式。一旦选中，你会发现对应的TX（PA12）和RX（PA11）引脚被自动分配并高亮。这里有个重要细节：即使在回环模式下，CubeMX依然会占用这两个GPIO口。虽然物理上它们不连接任何外部电路，但为了外设功能正常初始化，我们不要手动去禁用它们，保持CubeMX的自动分配即可。

2.2 参数配置：理解每一个选项的意义

点击CAN1进入参数设置。这里面的选项直接决定了CAN控制器的工作方式，不能瞎填。

1. Prescaler (分频器)：这是计算CAN总线波特率的核心。CAN总线时钟CAN_CLK来源于APB1时钟（PCLK1）。波特率 =CAN_CLK/ (Prescaler* (Time Quanta in Bit Segment1+Time Quanta in Bit Segment2+ 1))。

   • 假设PCLK1是36MHz，我们想配置成经典的500kbps。一个常用的配置是：Prescaler=6，Time Quanta in Bit Segment1=13，Time Quanta in Bit Segment2=2。那么，时间份额tq = 1 / (CAN_CLK / Prescaler) = 1 / (36MHz / 6) ≈ 167ns。比特时间 = (13+2+1) * 167ns ≈ 2.67us，对应波特率 ≈ 374.5kbps。要精确达到500kbps，可以调整分频或时间段，例如Prescaler=4，Segment1=9，Segment2=4，这样tq=111ns，比特时间=(9+4+1)111ns=2.0us，正好500kbps。我建议初次测试直接用1Mbps，通信更快，配置更简单：Prescaler=9，Segment1=4，Segment2=3（计算：(4+3+1)(1/(36M/9)) = 8 * 250ns = 2us? 这里我算错了，重新算：tq=1/(36M/9)=250ns，比特时间=8250ns=2us，波特率=500kbps。要达到1Mbps，需Prescaler=4，Segment1=9，Segment2=4？不对，这样tq=111ns，比特时间=14111ns=1.55us，约645kbps。更精确的1Mbps配置：Prescaler=3，Segment1=10，Segment2=3，tq=83.3ns，比特时间=14*83.3ns=1.17us？这不对。我们简化，使用CubeMX自带的波特率计算器或常用值：对于36MHz的PCLK1，Prescaler=3，Segment1=5，Segment2=3，则tq=83.3ns，比特时间=(5+3+1)*83.3ns=750ns，波特率≈1.33Mbps。其实对于回环测试，波特率只要芯片自身收发一致即可，不是关键，我们可以先选一个常见值，如500kbps：Prescaler=9，Segment1=13，Segment2=2（这是CAN标准采样点靠后的配置）。

2. Time Quanta in Bit Segment1/2：这两个参数定义了CAN比特位的构成。Segment1包含传播时间段和相位缓冲段1，Segment2是相位缓冲段2。Synchronization Jump Width通常设为1。对于初学者，一个稳健的500kbps配置可以是：Prescaler=9，Time Quanta in Bit Segment1=13，Time Quanta in Bit Segment2=2，Synchronization Jump Width=1。这个配置采样点位于(13+1)/(13+2+1)=87.5%处，比较靠后，抗干扰能力强。

3. Operating Mode：选择Normal即可。这里容易混淆：上面的Loopback是功能模式，这里的Normal是操作模式（相对于睡眠、初始化等）。在回环功能模式下，操作模式仍为Normal。

4. 其他参数：Automatic Bus-Off Management和Automatic Wake-Up Mode可以先禁用。Time Triggered Communication Mode也禁用，这是用于CAN FD等高级功能的。

2.3 滤波器配置：为什么回环测试可以“裸奔”

CAN控制器有强大的报文过滤功能，但在回环测试中，我们可以暂时让它“裸奔”，即接收所有报文。在CAN1的Configuration标签下，找到Filter Settings。

点击Add添加一个滤波器。将Filter Mode设置为Mask mode（掩码模式），Filter Scale设置为32-bit（简单）。关键在这里：

• Filter ID High/Low: 设为0。
• Filter Mask ID High/Low: 也设为0。

这个配置的含义是：滤波器ID为0，掩码也为0。在掩码模式下，掩码位为0表示对应的ID位是“不关心”（don‘t care）。掩码全为0，就意味着任何ID的报文都不被过滤，全部接收。这非常适合我们初期的测试，避免因为ID不匹配而收不到数据。

最后，在NVIC Settings中，可以勾选CAN1 RX0 interrupts，启用接收中断。这样当接收到报文时，CPU会被中断，我们可以在中断回调函数里处理数据。这对于后续做异步通信非常有用。

配置完成后，点击Project Manager，设置好工程名称、路径、IDE（MDK-ARM V5），将Code Generator中的Generated files设置为Generate peripheral initialization as a pair of ‘.c/.h’ files per peripheral，这样代码结构更清晰。然后点击GENERATE CODE生成工程。

3. HAL库代码实战：从发送到接收的完整链路

用Keil打开生成的工程。CubeMX已经为我们初始化了CAN外设和GPIO。我们的任务是在main.c的用户代码区添加业务逻辑。

3.1 初始化与启动：确保控制器就绪

首先，在/* USER CODE BEGIN 2 */部分，我们需要启动CAN外设。虽然CubeMX生成了初始化函数MX_CAN1_Init()，但它只完成了配置，没有启动CAN控制器。我们需要手动启动：

/* USER CODE BEGIN 2 */ // 启动CAN1控制器 if (HAL_CAN_Start(&hcan1) != HAL_OK) { // 启动错误处理，可以点亮一个LED指示错误 Error_Handler(); } // 启用CAN接收中断（如果之前NVIC中已启用） // HAL_CAN_ActivateNotification(&hcan1, CAN_IT_RX_FIFO0_MSG_PENDING); // 对于简单的轮询测试，可以先不用中断 /* USER CODE END 2 */

HAL_CAN_Start()这个函数非常关键，它使能了CAN控制器，让其进入正常工作状态。忘记调用它，CAN控制器就处于初始化或停止状态，无法收发报文。这是第一个常见的坑。

3.2 组装与发送报文：理解CAN帧结构

接下来，我们准备一个发送函数。在/* USER CODE BEGIN 4 */区域，或者自己新建一个can_app.c文件，编写发送函数。

/* USER CODE BEGIN 4 */ /** * @brief 发送一帧标准数据帧 * @param id: 标准ID (11位) * @param data: 数据数组指针 * @param len: 数据长度 (0-8) * @retval HAL status */ HAL_StatusTypeDef CAN_Send_StdData(uint32_t id, uint8_t* data, uint8_t len) { CAN_TxHeaderTypeDef TxHeader; uint32_t TxMailbox; // 1. 配置发送报文头 TxHeader.StdId = id; // 使用标准ID TxHeader.ExtId = 0; // 扩展ID未使用 TxHeader.IDE = CAN_ID_STD; // 标识符类型：标准帧 TxHeader.RTR = CAN_RTR_DATA; // 帧类型：数据帧（非远程请求帧） TxHeader.DLC = len; // 数据长度码 (0-8) TxHeader.TransmitGlobalTime = DISABLE; // 时间触发功能禁用 // 2. 调用HAL库发送函数 // 参数：CAN句柄，报文头指针，数据指针，用于返回邮箱号的变量指针，超时时间 if (HAL_CAN_AddTxMessage(&hcan1, &TxHeader, data, &TxMailbox) != HAL_OK) { return HAL_ERROR; } // 可选：等待发送完成，或者通过中断/回调处理 // while(HAL_CAN_GetTxMailboxesFreeLevel(&hcan1) != 3); // 等待所有邮箱空闲 return HAL_OK; } /* USER CODE END 4 */

逐行解析：

• CAN_TxHeaderTypeDef：这个结构体定义了一帧CAN报文的所有“元信息”，除了实际数据。
• StdId和ExtId：标准帧用11位ID，存在StdId里；扩展帧用29位ID，存在ExtId里。两者互斥，由IDE字段决定用哪个。
• IDE：CAN_ID_STD表示标准帧，CAN_ID_EXT表示扩展帧。回环测试两者都支持，但标准帧更常用。
• RTR：CAN_RTR_DATA表示数据帧；CAN_RTR_REMOTE表示远程帧，用于向其他节点请求数据。我们测试只用数据帧。
• DLC：数据长度码，范围0-8，表示后面跟着几个字节的数据。即使长度为0，也是一帧合法的数据帧。
• HAL_CAN_AddTxMessage：这是HAL库的核心发送API。它把报文头和数据放入CAN控制器的发送邮箱，由硬件自动完成后续的位定时、仲裁、CRC计算和发送。TxMailbox会返回使用的是哪个发送邮箱（0,1,2），可用于查询发送状态。

3.3 轮询接收报文：最简单的验证方式

发送出去了，怎么知道回环成功了呢？我们需要一个接收函数。在中断方式之前，先用最简单的轮询方式。

/** * @brief 轮询接收一帧CAN报文（非阻塞） * @param RxHeader: 用于存放接收报文头的结构体指针 * @param RxData: 用于存放接收数据的数组指针 * @retval HAL status: HAL_OK表示收到，HAL_ERROR表示未收到或错误 */ HAL_StatusTypeDef CAN_Poll_Receive(CAN_RxHeaderTypeDef* RxHeader, uint8_t* RxData) { // 检查FIFO0是否有 pending 的报文 if (HAL_CAN_GetRxFifoFillLevel(&hcan1, CAN_RX_FIFO0) > 0) { // 从FIFO0读取一帧报文 if (HAL_CAN_GetRxMessage(&hcan1, CAN_RX_FIFO0, RxHeader, RxData) == HAL_OK) { return HAL_OK; } } return HAL_ERROR; }

然后在主循环/* USER CODE BEGIN WHILE */中，我们可以这样组织测试逻辑：

/* USER CODE BEGIN WHILE */ uint8_t TxData[8] = {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88}; uint8_t RxData[8]; CAN_RxHeaderTypeDef RxHeader; uint32_t last_send_time = 0; const uint32_t send_interval = 1000; // 发送间隔，ms while (1) { /* USER CODE END WHILE */ /* USER CODE BEGIN 3 */ // 每隔1秒发送一帧 if (HAL_GetTick() - last_send_time > send_interval) { last_send_time = HAL_GetTick(); if (CAN_Send_StdData(0x123, TxData, 8) == HAL_OK) { // 发送成功，可以翻转一个LED指示 HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); } } // 轮询接收 if (CAN_Poll_Receive(&RxHeader, RxData) == HAL_OK) { // 成功收到一帧！这里可以比较接收到的ID和数据是否与发送的一致 // 例如，通过串口打印出来 // printf("Recv ID:0x%03X, Len:%d, Data:", RxHeader.StdId, RxHeader.DLC); // for(int i=0; i<RxHeader.DLC; i++) printf("%02X ", RxData[i]); // printf("\r\n"); // 简单验证：如果ID和数据匹配，再翻转一个LED if (RxHeader.StdId == 0x123 && RxHeader.DLC == 8) { uint8_t match = 1; for(int i=0; i<8; i++) { if(RxData[i] != TxData[i]) match = 0; } if(match) { // 回环成功！用另一个LED指示 // HAL_GPIO_TogglePin(LED2_GPIO_Port, LED2_Pin); } } } // 注意：这里没有延时，会全速轮询。可以根据实际情况加短延时。 } /* USER CODE END 3 */

这段代码实现了一个经典的“发送-接收-验证”循环。每隔1秒，它用ID 0x123发送8个字节的固定数据。然后不断轮询接收FIFO，一旦收到报文，就检查ID和数据是否与发送的一致。如果一致，就证明回环通路是畅通的，CAN控制器配置和基础驱动代码工作正常。

4. 进阶：中断接收与调试技巧

轮询方式简单，但占用CPU。在实际项目中，我们更常用中断方式。CubeMX已经帮我们生成了中断服务函数CAN1_RX0_IRQHandler，并在stm32f1xx_it.c中调用了HAL_CAN_IRQHandler。我们需要做的是实现接收完成回调函数。

4.1 实现接收回调函数

首先，在main.c的/* USER CODE BEGIN 4 */区域，或者在你的应用文件中，重写弱定义的HAL_CAN_RxFifo0MsgPendingCallback函数。

/** * @brief CAN FIFO0 消息挂起回调函数（中断方式） * @param hcan: CAN句柄指针 * @retval None */ void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { CAN_RxHeaderTypeDef RxHeader; uint8_t RxData[8]; // 确保是CAN1的中断 if (hcan->Instance == CAN1) { // 从FIFO0读取报文 if (HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, &RxHeader, RxData) == HAL_OK) { // 在这里处理接收到的报文 // 例如，将数据和ID存入一个队列，在主循环中处理 // 或者直接进行简单的响应 // user_process_can_frame(&RxHeader, RxData); // 简单示例：翻转LED HAL_GPIO_TogglePin(LED2_GPIO_Port, LED2_Pin); } } }

然后，在main函数的初始化部分（USER CODE BEGIN 2），在启动CAN后，需要激活接收中断通知：

/* USER CODE BEGIN 2 */ if (HAL_CAN_Start(&hcan1) != HAL_OK) { Error_Handler(); } // 激活FIFO0消息挂起中断 if (HAL_CAN_ActivateNotification(&hcan1, CAN_IT_RX_FIFO0_MSG_PENDING) != HAL_OK) { Error_Handler(); } /* USER CODE END 2 */

这样，每当CAN控制器接收到一帧报文并放入FIFO0时，就会触发中断，并自动调用上面的回调函数。这里有个关键点：回调函数是在中断上下文执行的，所以要快进快出，避免执行耗时操作。通常的做法是将数据拷贝到缓冲区，然后通过标志位通知主循环处理。

4.2 调试与验证：当代码不工作时怎么办

即使按照步骤做了，第一次也可能不成功。别慌，这是常态。下面是我总结的排查清单：

1. 检查时钟配置：这是最隐蔽的坑。确保CAN_CLK（即PCLK1）有正确的时钟。可以在main函数初始化后，通过SystemCoreClock变量或查看RCC相关寄存器来确认。如果CAN时钟不对，波特率计算就全错了。

2. 确认CAN控制器已启动：务必检查HAL_CAN_Start()的返回值，并可以在其后读取CAN控制器的MSR寄存器（通过hcan1.Instance->MSR），检查INAK位是否被清除（表示已离开初始化模式）。

3. 检查滤波器配置：虽然我们设置了全接收，但也要确认滤波器是否确实被激活。在MX_CAN1_Init()函数末尾，HAL库会调用HAL_CAN_ConfigFilter。确保它的参数和你CubeMX里设置的一致。你可以单步调试，看看这个函数是否返回HAL_OK。

4. 利用HAL库的状态和错误句柄：hcan1这个结构体里有State和ErrorCode成员。在调试时，可以监视这些变量。例如，发送失败后查看hcan1.ErrorCode，可能提示“仲裁丢失”、“总线错误”等（虽然在回环模式下这些错误较少见）。

5. 发送邮箱状态：调用HAL_CAN_AddTxMessage后，可以通过HAL_CAN_GetTxMailboxesFreeLevel(&hcan1)查看空闲邮箱数量。如果一直是3，可能根本没启动发送；如果变成2，说明有一个邮箱正在使用或等待发送。

6. 接收FIFO状态：使用HAL_CAN_GetRxFifoFillLevel函数。在发送后，如果这个值从0变成1，说明报文确实被接收到了，只是可能ID或数据没对上。如果一直是0，那问题可能出在发送端或回环模式未生效。

7. 最直接的验证：使用调试器查看寄存器。这是终极手段。查看CAN控制器的ESR（错误状态寄存器）、TSR（发送状态寄存器）、RF0R（接收FIFO0寄存器）。例如，RF0R的FMP0位会直接告诉你FIFO0里有多少帧报文。如果发送后FMP0位没有增加，那问题一定在发送或全局配置上。

8. 代码逻辑：检查你的发送ID和接收比较的ID是否完全一致（都是十六进制0x123）。检查数据长度DLC。确保接收数据数组足够大。

注意：回环测试成功，只证明了从软件到CAN控制器内部的路径是通的。当你切换到Normal模式连接真实总线时，还会遇到物理层的问题，比如终端电阻、共模电压、布线等，那是另一个维度的挑战了。但至少，你已经排除了软件配置这个最大的不确定性。