★ FEATURED ARTICLE 1. 串口中断收不到数据问题到底出在哪刚接触 STM32 HAL 库那会儿我最头疼的就是串口中断接收。明明HAL_UART_Receive_IT也调了中断优先级也配了MX_USART1_UART_Init里波特率、字长、停止位全对可就是进不了HAL_UART_RxCpltCallback。有时候单步调试能进全速跑就丢数据有时候第一帧能收后面全卡死。这种问题在论坛上几乎每周都有人问而且答案往往不在 HAL 库本身而在于我们对它那套“状态机 回调”机制的理解有偏差。这篇内容就是把我这些年踩过的坑、帮别人排查过的案例系统地梳理一遍。核心围绕STM32 HAL 库 UART 中断接收展开重点讲清楚HAL_UART_Receive_IT到底做了什么、回调函数为什么不执行、以及怎么用一套可复现的方法把问题定位出来。适合已经能点灯、能跑通串口打印但一上中断接收就翻车的朋友。如果你正在做基于 STM32 的项目比如串口屏通信、模组 AT 指令交互、上位机协议解析这篇文章里的排查思路可以直接拿去用。先说结论回调不执行九成以上不是 HAL 库有 bug而是下面这几类原因——中断没真正使能、接收状态被占用、回调函数名写错、中断标志没清、优先级配置冲突、以及最隐蔽的“只调用了一次 Receive_IT 却想收多帧”。下面逐个拆开讲。2. HAL_UART_Receive_IT 内部到底干了什么2.1 从函数原型看它的三个动作很多人把HAL_UART_Receive_IT当成一个“启动接收”的开关调一次就以为串口会一直收。实际上它的原型是这样的HAL_StatusTypeDef HAL_UART_Receive_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)它做三件事第一检查huart-RxState是不是HAL_UART_STATE_READY如果不是就直接返回HAL_BUSY什么都不做第二把用户缓冲区指针pData和长度Size存进句柄设置RxState HAL_UART_STATE_BUSY_RX第三使能接收相关中断RXNE、PE、ERR 等等待数据到来。关键就在第一步。RxState是一个状态锁只要上一次接收还没完成它就一直是BUSY_RX你再调多少次Receive_IT都会被拒绝。这就是为什么“第一帧能收后面收不到”——因为第一帧收完后如果你没有在回调里重新调用Receive_IT状态虽然回到了 READY但中断接收没有被重新武装自然不会有下一帧。2.2 中断服务函数里的状态流转数据到来时USART1_IRQHandler会调用HAL_UART_IRQHandler。这个函数内部会根据标志位判断如果是 RXNE读数据寄存器非空就把数据搬进缓冲区RxXferCount减一当计数减到 0说明收满了Size个字节于是关闭接收中断把RxState置回 READY然后调用HAL_UART_RxCpltCallback。注意这个顺序先收满再回调。也就是说如果你Size设的是 10但对方只发了 5 个字节回调永远不会触发因为RxXferCount没到 0。这是新手最容易误解的地方——以为收到任意数据就会回调。HAL 库的接收完成中断是“定长触发”不是“任意长度触发”。2.3 回调函数的弱定义机制HAL_UART_RxCpltCallback在 HAL 库的stm32f1xx_hal_uart.c里是用__weak修饰的空函数。你如果在自己的main.c或usart.c里重新定义了一个同名函数链接器会用你的覆盖弱定义。但如果你函数名拼错一个字母比如写成HAL_UART_RxCompleteCallback编译器不会报错链接器也不会报错因为弱定义还在结果就是你的函数永远不会被调用。这种问题用“编译通过但没反应”来描述最贴切排查时优先检查拼写。3. 回调不执行的六大原因逐个排查3.1 原因一中断根本没使能这是最基础也最容易被忽略的。HAL_UART_Receive_IT内部会调用__HAL_UART_ENABLE_IT来使能 RXNE 中断但前提是 NVIC 里 USART1 的中断通道已经使能。如果你用的是 CubeMX 生成的代码NVIC 配置通常没问题但如果是手动移植的工程很可能只调了Receive_IT却没开 NVIC。检查方法很简单在main里调用Receive_IT之后读一下USART1-CR1的 RXNEIE 位再看NVIC-ISER里对应位。更直接的办法是在USART1_IRQHandler里打个断点或翻转 IO看数据到来时到底进没进中断。如果 IO 不翻转说明中断通道没通跟回调没关系。注意有些朋友在 CubeMX 里勾了“USART1 global interrupt”但生成代码后又在别处把HAL_NVIC_DisableIRQ调了一遍这种自相矛盾的操作也会导致中断失效。3.2 原因二RxState 被占用导致 Receive_IT 返回 BUSY前面说过RxState是状态锁。常见场景是你在初始化时调了一次Receive_IT然后在主循环里又调了一次第二次返回HAL_BUSY你以为“已经启动了”实际上第一次的接收还没完成。更隐蔽的是如果你同时用了HAL_UART_Receive阻塞式和HAL_UART_Receive_IT阻塞式接收会把状态占住中断式调用直接失败。排查手段在每次调用Receive_IT后打印返回值。如果是HAL_BUSY说明状态没释放。这时候要检查是不是有未完成的接收或者中断里出现了错误标志ORE、FE、NE导致状态卡死。3.3 原因三回调函数名拼写错误或没放在正确文件这个坑我见过太多次。HAL 库的回调名是固定的HAL_UART_RxCpltCallback接收完成HAL_UART_TxCpltCallback发送完成HAL_UART_ErrorCallback错误有人写成HAL_UART_ReceiveCallback有人把Cplt写成Complete还有人把函数定义在了一个没被编译进工程的.c文件里。这些情况编译器都不报错因为弱定义兜底了。验证方法在回调函数里加一句__NOP()或翻转一个 IO然后全速运行。如果 IO 不动先确认函数名。另一个办法是在HAL_UART_RxCpltCallback的弱定义处打断点看程序是不是停在了弱定义里——如果是说明你的重定义没生效。3.4 原因四中断标志没清导致反复进中断或卡死UART 有几个错误标志ORE溢出、FE帧错误、NE噪声、PE校验错误。这些标志如果不处理会导致中断反复触发HAL_UART_IRQHandler里会调用ErrorCallback而RxState可能被置为 READY 但接收中断没重新使能表现就是“进了一次错误回调后再也收不到数据”。处理办法在HAL_UART_ErrorCallback里根据错误类型做清理然后重新调用HAL_UART_Receive_IT。对于 ORE通常需要读 SR 再读 DR 来清除。HAL 库在HAL_UART_IRQHandler里已经做了一部分清理但如果你在错误回调里什么都不做状态机可能停在异常分支。3.5 原因五中断优先级配置冲突STM32 的中断优先级分抢占优先级和子优先级。如果 USART1 的抢占优先级比某个正在执行的中断低而那个中断又长时间不退出串口中断就会被延迟甚至丢失。更常见的是在HAL_UART_RxCpltCallback里调用了HAL_Delay或其他阻塞函数导致中断响应变慢下一帧数据到来时 ORE 溢出。原则串口中断的抢占优先级要足够高数值小回调里只做标志置位、数据搬运这类快操作耗时处理放到主循环。如果用了 RTOS回调里用xQueueSendFromISR而不是普通xQueueSend。3.6 原因六只调一次 Receive_IT 却想收多帧这是最经典的“第一帧正常后面全丢”。HAL 库的Receive_IT是单次定长接收收满Size个字节后中断自动关闭。如果你想连续接收必须在HAL_UART_RxCpltCallback里再次调用HAL_UART_Receive_IT重新武装接收。void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { // 处理刚收到的数据 process_rx_buffer(rx_buf, RX_SIZE); // 重新启动接收 HAL_UART_Receive_IT(huart1, rx_buf, RX_SIZE); } }注意重新调用时RxState已经是 READY所以能成功。如果你在回调外的主循环里调用可能因为状态还没释放而返回 BUSY。4. 一套可复现的最小接收工程4.1 硬件与工具准备我用的是一块常见的 STM32F103C8T6 最小系统板USB 转串口模块一个杜邦线若干。软件方面Keil MDK 5 或者 STM32CubeIDE 都行CubeMX 用来生成初始化代码。串口助手用任意一款都行波特率设 1152008 数据位1 停止位无校验。接线USB 转串口的 TX 接 STM32 的 PA10RXRX 接 PA9TXGND 共地。注意不要接错TX 对 TX 是收不到数据的。4.2 CubeMX 关键配置在 CubeMX 里选好芯片后配置 USART1 为异步模式波特率 115200。NVIC 里勾上“USART1 global interrupt”抢占优先级设 1子优先级设 0。GPIO 里 PA9 和 PA10 会自动配成复用推挽和浮空输入。生成代码时选择“Copy only necessary library files”这样工程干净。生成后的MX_USART1_UART_Init里会调用HAL_UART_Init但不会自动调用Receive_IT。我们需要在main里手动加。4.3 接收代码的完整写法#define RX_SIZE 10 uint8_t rx_buf[RX_SIZE]; volatile uint8_t rx_flag 0; int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART1_UART_Init(); HAL_UART_Receive_IT(huart1, rx_buf, RX_SIZE); while (1) { if (rx_flag) { rx_flag 0; // 处理数据比如回显 HAL_UART_Transmit(huart1, rx_buf, RX_SIZE, 100); HAL_UART_Receive_IT(huart1, rx_buf, RX_SIZE); } } } void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { rx_flag 1; } }这段代码的逻辑是初始化后启动一次接收收满 10 字节触发回调回调里只置标志主循环处理并重新启动接收。这样既避免了在中断里做耗时操作又保证了连续接收。4.4 验证步骤与现象烧录后打开串口助手发送 10 个字节比如1234567890。如果一切正常你会看到串口助手收到同样的 10 个字节。如果没反应按下面的顺序查先看HAL_UART_Receive_IT返回值是不是 HAL_OK再看USART1_IRQHandler有没有被触发再看回调有没有进最后看主循环有没有执行到发送。我实测下来这套最小工程在 F103 上很稳连续发几百帧都不丢。关键就是回调里重新武装接收这一步不能忘。5. 常见问题速查与避坑心得5.1 问题速查表现象可能原因排查方法解决完全进不了中断NVIC 没使能在 IRQHandler 打断点检查 CubeMX NVIC 配置第一帧正常后面丢没重新调 Receive_IT看回调里有没有重新启动回调里加 Receive_IT编译通过但回调不执行函数名拼错检查拼写和文件改成 HAL_UART_RxCpltCallback进一次错误回调后卡死错误标志没清看 ErrorCallback清理标志并重启接收数据偶尔丢失优先级太低或回调太长看 ORE 标志提高优先级缩短回调返回 HAL_BUSYRxState 被占用打印返回值等上一次完成再调5.2 独家避坑技巧第一个技巧在HAL_UART_RxCpltCallback里不要用printf。printf重定向到串口后是阻塞发送在中断里调用会拖慢中断响应甚至导致下一帧溢出。要调试就用 IO 翻转或者往数组里存标志。第二个技巧如果你用的是 DMA 接收HAL_UART_Receive_DMA和Receive_IT不能混用。DMA 模式下回调是HAL_UART_RxCpltCallback但状态管理不同混用会导致状态锁死。第三个技巧串口助手的发送间隔不要太短。有些助手连续发送时帧间隔只有几毫秒如果 MCU 主频低、中断处理慢很容易 ORE。测试时先手动单次发送确认通路后再试连续发送。第四个技巧如果你在回调里重新调用Receive_IT时返回 BUSY大概率是因为你在回调里又调了别的阻塞函数导致状态没及时释放。把阻塞操作挪到主循环。5.3 关于 HAL 库和标准库的取舍网上经常有人争论 HAL 库效率低、标准库更直接。我的看法是HAL 库的 UART 中断接收确实多了一层状态机但它的可移植性和 CubeMX 的配套让开发速度快很多。标准库的USART_ITConfig加自己写 IRQHandler 更灵活但换个芯片就要重写。对于大多数项目HAL 库够用关键是把它的状态机逻辑吃透。如果你实在嫌 HAL 慢可以用 LL 库或者直接操作寄存器但那就另说了。6. 从单字节到不定长接收的扩展思路6.1 单字节接收的写法如果你不需要定长可以每次只收 1 个字节在回调里存进环形缓冲区然后重新启动接收。这样能实现不定长接收代价是中断频率高。写法uint8_t rx_byte; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { ring_buf_put(rx_byte); HAL_UART_Receive_IT(huart1, rx_byte, 1); } }主循环里从环形缓冲区取数据按协议解析帧头帧尾。这种方式在 115200 波特率下完全跟得上我实测过连续发 1KB 数据不丢。6.2 空闲中断配合接收更优雅的方案是用空闲中断IDLE判断一帧结束。HAL 库没有直接提供空闲中断回调但可以自己使能 IDLE 中断在USART1_IRQHandler里判断 IDLE 标志然后调用HAL_UART_DMAStop或读取已接收长度。这种方式配合 DMA 最舒服CPU 占用极低。不过它涉及 DMA 配置和中断标志手动清理比纯中断接收复杂一些建议先把本文的定长接收跑通再上。6.3 环形缓冲区的必要性不管用哪种方式只要数据速率不低都建议加环形缓冲区。中断里只负责把数据塞进缓冲区主循环慢慢解析。这样中断执行时间短不容易丢数据。缓冲区大小根据你的最大帧长和主循环处理速度来定一般 256 或 512 字节够用。7. 我个人在实际项目中的几点体会做串口通信这些年我最大的体会是不要相信“应该没问题”要相信示波器和断点。很多问题看起来是软件问题实际是硬件接线、电平匹配、波特率误差导致的。比如 USB 转串口模块质量差波特率偏差大就会间歇性丢帧。这时候你怎么改代码都没用换模块就好了。另外HAL 库的回调机制虽然方便但它的状态机是全局的一个 UART 句柄同一时间只能有一个接收任务。如果你在多处调用Receive_IT一定要确保前一次已经完成。我习惯在每次调用后检查返回值不是 HAL_OK 就记录错误码这样排查起来有据可依。最后分享一个小习惯在HAL_UART_ErrorCallback里把错误码存到一个全局变量主循环里打印出来。这样即使不接调试器也能知道是 ORE 还是 FE定位问题快很多。串口这东西通了之后很稳不通的时候处处是坑把本文的排查顺序走一遍基本都能解决。
阅读完成 · 觉得有帮助？
