STM32 HAL库串口DMA发送卡死？从状态机到中断的排查与解决

对一个做嵌入式开发的人来说没有比这种问题更让人烦躁的了上电第一包数据发送得很顺利串口助手也收到了可紧接着第二包、第三包就像石沉大海怎么调都没反应。程序看起来没毛病HAL_UART_Transmit_DMA也确实被调用了但串口就是不吐数据。如果你也被这个“STM32 HAL库串口DMA发送卡死”的问题折磨过那这篇文章就是为你准备的。你搜索到的“STM32、HAL库、串口、DMA、HAL_UART_Transmit_DMA”这些关键词组合起来指向一个非常经典的嵌入式开发场景使用STM32的HAL库通过DMA方式驱动串口发送数据。这个问题比很多人想象中更普遍尤其在刚接触CubeMXHAL库的新手里几乎每隔几天就有人在技术社区问一遍。但说句实话这坑的根源并不复杂核心在于HAL库内部那套状态机机制以及不少人对DMA含义的惯性误解。接下来我按自己踩坑时一步步排查的思路把这问题彻底讲透。1. 问题现场还原为什么会“只能发一次”不绕弯子先看一个极具代表性的错误写法。假设你用STM32F103C8T6通过CubeMX生成工程串口1配置为异步模式波特率115200DMA发送通道选择USART1_TX然后在主循环里写类似下面的代码uint8_t data[10] 0123456789; while (1) { HAL_UART_Transmit_DMA(huart1, data, 10); HAL_Delay(500); }指望的效果是每500ms通过串口发一次数据。但实际表现往往是第一次上电串口助手能收到“0123456789”之后就再也不动了。如果你用的是逻辑分析仪或者示波器去抓USART1_TX引脚会发现只有第一包数据的波形后面完全静默。更让人摸不着头脑的是如果换用阻塞发送HAL_UART_Transmit哪怕在同一个循环里连续发几十次每次都正常。于是很多人就开始怀疑DMA配置有问题或者怀疑中断没配置好甚至怀疑芯片坏了。其实芯片好端端的问题出在HAL库对“上一次DMA传输是否真正完成”的管理上。这块你必须要意识到一个关键差异HAL_UART_Transmit是阻塞发送函数内部会死等发送完成把串口状态机复位回“READY”然后才返回而HAL_UART_Transmit_DMA是异步发送函数调用后立即返回真正发送完成的信号通过DMA中断/串口中断在后台触发。如果这个“后台完成信号”没有被正确建立起来状态机就永远停在“BUSY”表现为第二次及以后的调用全部无声失败。2. 刨根问底HAL库串口发送状态机到底做了什么很多人不理解为什么“第二次调用”会失效这就要深入到HAL库内部的状态管理逻辑。以HAL_UART_Transmit_DMA为例函数开头几行有个核心判断我截取关键片段如下HAL_StatusTypeDef HAL_UART_Transmit_DMA(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size) { /* Check that a Tx process is not already ongoing */ if (huart-gState HAL_UART_STATE_READY) { // 执行DMA发送配置... huart-gState HAL_UART_STATE_BUSY_TX; } else { return HAL_BUSY; } }看到这里你应该就明白了。HAL库用一个状态字段gState来标记当前串口是否空闲只有当gState HAL_UART_STATE_READY时才允许发起新的传输。第一次上电时gState是READY于是发送成功gState被置为BUSY_TX。第二次进入函数时这个字段还停在BUSY_TX判断条件不满足函数直接返回HAL_BUSYDMA根本没有启动。那么问题就转化为什么情况下本应把gState从BUSY_TX复位回READY的代码没有执行答案藏在DMA中断完成处理链路里。发送完成后正常流程是这样的DMA传输完成触发DMA中断 - HAL_DMA_IRQHandler()被调用 - 判断DMA传输完成标志 - 调用UART_DMATransmitCplt()内部函数 - 复位huart-gState HAL_UART_STATE_READY - 调用用户重写的HAL_UART_TxCpltCallback()回调函数这条链路里任何一个环节断了比如DMA中断没有在NVIC里使能、中断处理函数没写、或者回调里做了一些阻塞操作导致流程不完整gState就永远不会回到READY。另一个比较容易混淆的点是CubeMX配置DMA时会有一个DMA Request和DMA Channel映射如果这里配置错了或者你手动改了启动文件里的中断向量名也会导致同样的现象。不过对大多数人来说最大的坑就是中断没使能或者回调没写。下文我会把排查方法按步骤列清楚。3. 逐步排查像我一样用调试器定位卡死点如果遇到“只能发一次”的情况别急着怀疑硬件先用调试器看几个关键点。我个人习惯使用SWD接口通过ST-Link连接在Keil或STM32CubeIDE里打开调试会话。下面按排查顺序整理了一份非常实用的步骤3.1 第一步确认gState的值是否异常在第二次调用HAL_UART_Transmit_DMA的位置打断点程序跑起来后停住把huart1.gState加入Watch窗口。正常情况下如果卡死问题存在你会看到它的值是HAL_UART_STATE_BUSY_TX在HAL库里这个枚举对应数值通常是0x21。如果确实是这个值就说明上一次传输没有正常结束问题几乎可以锁定在“完成通知机制”上。3.2 第二步检查DMA中断是否在NVIC中使能进入CubeMX的NVIC设置页展开DMA相关中断向量确认DMA1_Channel4_IRQnF103的USART1_TX对应DMA1的Channel4已经被勾选。这里千万注意CubeMX中UART的DMA发送通道和接收通道会各自生成一个中断请求很多工程只勾选了接收漏掉了发送于是接收正常、发送只能发一次。如果你是完全手动写代码不经过CubeMX还要确认在HAL_UART_MspInit里有HAL_NVIC_EnableIRQ(DMA1_Channel4_IRQn)这类调用。3.3 第三步在回调函数里打断点验证调用链编译下载后在HAL_UART_TxCpltCallback函数里加断点。如果这个回调压根没被触发说明DMA中断没有真正进来或者DMA传输完成标志没被处理。如果回调被触发了但gState仍然不是READY那就说明你在回调里改坏了某些状态或者使用了非中断安全的操作。提示HAL_UART_TxCpltCallback默认是__weak弱定义你必须自己重写一个强定义版本。很多人忘了写这个回调还指望着发送完成后自动发生什么这是不现实的。回调函数本身只是一个通知机制你可以什么都不做但状态机复位是由HAL内部函数完成的不依赖用户回调是否被重写。3.4 第四步检查DMA当前传输状态寄存器在调试器里打开外设寄存器窗口找到DMA1对应的Channel4寄存器重点看CNDTR当前传输数据计数寄存器的值。如果它不为0说明DMA传输还没结束如果已经为0但状态仍然没复位大概率是中断处理出现了问题。正常情况下一次完整传输结束后CNDTR会变成0之后再发起新的发送时又会重新载入长度。3.5 第五步用逻辑分析仪抓波形辅助判断波形层面能直接看出来“有没有发送行为”。很多新手只依赖串口助手的接收结果其实不完全可靠因为串口助手只有在收到完整有效数据帧时才显示。用逻辑分析仪抓USART1_TX引脚可以看到起始位和电平变化特别适合区分“软件压根没启动DMA”和“DMA启动了但数据内容不对”。4. 彻底解决从简单修补到可靠异步发送模块定位到具体原因之后解决办法就水到渠成了。如果只是因为中断没使能把NVIC勾上即可。但经验告诉我很多项目并不止一个坑更像是多个隐患叠加。所以这里我直接给出两级方案第一级是薄修补适合快速救火第二级是完整封装适合长期可靠的工程使用。4.1 薄修补方案发送前主动等待确保中断启用在调用HAL_UART_Transmit_DMA之前先判读gState状态如果还在忙碌就等它恢复正常顺便加一个超时保护避免死循环。这种方法比较“无脑”适合数据量不大、调用频率不高的场景至少能保证不会再出现“只能发一次”的尴尬uint8_t UART_SendString_DMA(UART_HandleTypeDef *huart, uint8_t *data, uint16_t len) { uint32_t timeout 0xFFFF; // 等待上一次DMA发送完成 while (huart-gState ! HAL_UART_STATE_READY) { if (--timeout 0) { return 1; // 超时返回错误避免死等 } } if (HAL_UART_Transmit_DMA(huart, data, len) ! HAL_OK) { return 1; } return 0; }注意这里相当于把异步发送硬生生加上了同步等待牺牲了一部分DMA的“不占CPU”优势。但它能让问题立刻消失先把业务跑通再追求性能优化。而且我还加了一句关键话如果有超时保护就不要用while(1)死等否则一旦链路再次出问题整个系统会被锁死。4.2 完整封装发送标志位主循环轮询要把异步特性真正发挥出来推荐维护一个“发送忙标志”在发送完成回调里清除然后在主循环里判断标志后再发下一包。这个方案不阻塞CPU也不会卡死还能保持代码逻辑简洁。下面是一个典型实现思路typedef struct { UART_HandleTypeDef *huart; volatile uint8_t txBusy; uint8_t txBuffer[256]; uint16_t txLen; } UART_Driver; UART_Driver g_uart1; void UART_Driver_Init(UART_Driver *drv, UART_HandleTypeDef *huart) { drv-huart huart; drv-txBusy 0; drv-txLen 0; } uint8_t UART_Driver_Send(UART_Driver *drv, uint8_t *data, uint16_t len) { // 如果上一包还在发送拒绝接收新数据 if (drv-txBusy) { return 1; } if (len sizeof(drv-txBuffer)) { return 1; } memcpy(drv-txBuffer, data, len); // 注意必须先将缓冲数据复制到驱动的内部缓冲区再启动DMA drv-txLen len; drv-txBusy 1; if (HAL_UART_Transmit_DMA(drv-huart, drv-txBuffer, len) ! HAL_OK) { drv-txBusy 0; return 1; } return 0; } void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { if (huart g_uart1.huart) { g_uart1.txBusy 0; } }写这套代码时有几个细节你必须注意发送的数据必须拷贝到驱动内部缓冲区而不是直接指向调用者传入的栈上局部数组。因为HAL_UART_Transmit_DMA本质上只是把“缓冲区地址长度”登记给DMA控制器DMA会在后台搬运数据如果你传入的数组是局部变量函数返回后该内存就可能被覆盖发送内容会错乱。回调里不要做耗时操作也不要调用HAL_Delay。这是中断上下文应当尽量短小精悍。如果你的业务确实需要在发送完成后做大量处理正确做法是置一个事件标志回到主循环或RTOS任务里处理。如果工程里有多个串口都使用DMA发送HAL_UART_TxCpltCallback是全局回调你必须区分huart-Instance例如if (huart-Instance USART1)来分别处理。5. 更隐蔽的坑RTOS和低功耗场景下的状态错乱“只能发一次”的思路性根源解决后还有一类场景会让人新踩坑常见于带FreeRTOS或低功耗管理的项目。这里我把它单独拉出来讲因为排查路径和上面完全不同。5.1 FreeRTOS下发送任务优先级与中断优先级配置在FreeRTOS任务里如果直接调用HAL_UART_Transmit_DMA然后通过信号量或队列在TxCpltCallback里进行任务同步这种模式本身没问题。真正麻烦的是NVIC优先级配置。STM32的HAL库底层大量依赖中断和SysTick如果NVIC优先级分组设置不当可能导致DMA中断在临界区中被意外屏蔽。典型现象是有时候能发出去有时候又不能多试几次随机出错。我在实际项目中一般把NVIC优先级分组设置为NVIC_PRIORITYGROUP_4即全部4bit都用作抢占优先级不使用子优先级。这样配合FreeRTOS时可以把DMA中断优先级设置为比串口中断高一点确保在临界区内的中断响应足够及时。还有一个经验不要在发送前用taskENTER_CRITICAL()长时间关中断DMA的启动需要在中断开启状态下才能及时完成“传输完成”标志处理。如果出现一加RTOS就发不出去的情况优先检查两个地方中断优先级分配是否正确、SysTick中断是否被FreeRTOS接管后影响了HAL库的HAL_GetTick。HAL库很多地方依赖HAL_GetTick()做超时判断尤其是阻塞版本的HAL_UART_Transmit一旦HAL_GetTick不再递增发个串口都可能直接返回HAL_TIMEOUT。5.2 低功耗模式下DMA状态丢失在低功耗项目中进入STOP模式后DMA和串口的时钟默认会被关闭。等系统从STOP唤醒如果仅仅是把串口重新初始化而没有重新初始化DMA那么原本绑定的DMA请求就失效了发送函数调用后表现为“没反应”或“只能发一次”。解决办法很简单在进入低功耗之前调用HAL_UART_DeInit唤醒后重新调用HAL_UART_Init。CubeMX生成的HAL_UART_MspInit会在使能UART时钟的同时配置DMA所以重新init的过程会把DMA也一起拉起。但要注意如果你在HAL_UART_MspInit里做了其他一次性操作比如GPIO复用设置确认这些设置也能被重复执行而不会产生副作用。5.3 发送缓冲被复用导致的错乱假象还有一种极具迷惑性的场景表面上是“发送卡死”但实际是数据发错了。为什么这么说因为数据错乱会导致接收端解析失败甚至协议层卡死你看到的现象就是“数据没发出去”。这种情况通常和DMA异步特性有关。很多人会在一个全局循环里反复使用同一个发送缓冲区uint8_t buffer[64]; while (1) { sprintf((char *)buffer, hello %d\r\n, counter); HAL_UART_Transmit_DMA(huart1, buffer, strlen((char *)buffer)); HAL_Delay(20); }第一次发送时DMA登记了buffer的地址随后开始搬运。但在DMA搬运完成之前第二次循环又改写了buffer的内容导致发出的数据被篡改如果你的代码逻辑又依赖收到的数据长度判断是否成功就会出现“好像卡死又好像没卡死”的边界情况。解决思路还是回到我上面说的驱动内部缓冲区或者在写缓冲时先确认上一次发送已完成。6. 给项目锦上添花DMA接收与空闲中断的组合用法既然都讲到串口DMA了我就顺手把接收方向一起聊了因为收发通常是配套的。很多人在解决了发送问题之后紧接着会问“DMA接收怎么判断一帧数据什么时候结束”。这里推荐一个非常通用的方案空闲中断IDLE Line Interrupt DMA接收。STM32的串口外设在检测到总线上有一个字节时间的空闲电平后会触发IDLE中断。借助这个中断配合DMA接收可以实现“不定长数据帧接收”。HAL库提供了现成的函数HAL_UARTEx_ReceiveToIdle_DMA()CubeMX生成的F1/F4系列HAL库中通常都包含该接口。用法如下uint8_t rxBuffer[128]; // 启动接收等待任意长度数据 HAL_UARTEx_ReceiveToIdle_DMA(huart1, rxBuffer, sizeof(rxBuffer));当一帧数据到达并且总线空闲时回调HAL_UARTEx_RxEventCallback会被调用里面的Size参数告诉你实际收到了多少字节。然后你需要重新调用一次HAL_UARTEx_ReceiveToIdle_DMA来启动下一轮接收。这种模式下发送用DMA接收也用DMACPU占用率极低非常适合数据采集、OTA升级分包接收、通信协议解析等场景。这里有个不踩不行的坑如果你在同一个串口上同时用DMA接收和中断发送一定要确认CubeMX生成的DMA请求映射没有冲突。以STM32F103为例USART1_TX默认对应DMA1_Channel4USART1_RX对应DMA1_Channel5它们互不干扰。但如果你手写代码时偷懒把发送和接收都配置成同一个DMA通道就会发生数据错乱甚至完全无法工作的情况。另外一个实际工程中很有用的习惯在启动DMA接收之前先清一次串口的状态标志避免历史遗留的OREOverrun Error错误影响后续接收。HAL库底层有__HAL_UART_CLEAR_OREFLAG这样的宏也可以直接调用HAL_UART_AbortReceive()取消上一次未完成的接收后再重新启动。这类小细节通常是要在项目联调阶段才会被反反复复折磨后记住的。7. 常见问题与排查技巧小结为了方便你以后快速定位类似问题我把这个“串口DMA发送卡死”主题下最常见的情况整理成了一张速查表。你可以直接对应现象去找原因效率会高很多现象特征常见原因处理方式第二次调用HAL_UART_Transmit_DMA返回HAL_BUSYgState停留在BUSY_TXDMA完成中断链路断掉检查DMA中断NVIC使能、确认回调被正常调用、确认内部状态复位流程未被阻断发送能进DMA但串口无波形DMA请求映射错误或串口TX引脚复用到别的外设核对CubeMX中UART_TX对应的DMA通道检查GPIO复用配置发送内容随机错乱缓冲区被改、DMA登记了不稳定的内存地址拷贝到驱动内部缓冲区后启动DMA禁止发送未完成的缓冲复用加RTOS后串口异常中断优先级配置不当、SysTick被RTOS接管但HAL_GetTick未适配统一NVIC优先级分组为GROUP4确认HAL库的时基未失效从低功耗唤醒后串口失灵DMA时钟在STOP模式下被关闭未重新初始化唤醒后重新调用HAL_UART_Init保证HAL_UART_MspInit重新配置DMA发送回调里一调用发送函数就死机中断上下文里执行了阻塞或重入操作回调里只置标志实际发送放到主循环或RTOS任务中处理我还想特别强调一个排查技巧遇到串口相关诡异问题先把波特率降到9600甚至更低试一遍。这不是说波特率本身有问题而是低波特率下电平持续时间更长用示波器或逻辑分析仪更容易抓到完整波形方便判断硬件链路到底通不通。如果低波特率下一切正常再回头查软件配置能少走很多弯路。8. 从“能发”到“好用”一套最简串口DMA收发框架的完整示例理论讲了那么多最后献上一段可以“抄作业”的收发框架。这里只保留最核心的框架逻辑演示如何在项目里把发送、接收、主循环查询结合起来。它不一定适用于所有复杂业务但作为起步模板绰绰有余。后续你可以根据自己的协议把收到的数据解析、组帧、对比校验等业务按需加进去。#include main.h #define UART_BUF_SIZE 128 typedef struct { UART_HandleTypeDef *huart; uint8_t txBuf[UART_BUF_SIZE]; volatile uint8_t txBusy; uint8_t rxBuf[UART_BUF_SIZE]; volatile uint16_t rxLen; volatile uint8_t rxNewData; } Uart_Handle; Uart_Handle g_uart; uint8_t testData[UART_BUF_SIZE]; void Uart_Init(Uart_Handle *handle, UART_HandleTypeDef *huart) { handle-huart huart; handle-txBusy 0; handle-rxLen 0; handle-rxNewData 0; } uint8_t Uart_Send(Uart_Handle *handle, uint8_t *data, uint16_t len) { if (handle-txBusy || len UART_BUF_SIZE) { return 1; } memcpy(handle-txBuf, data, len); handle-txBusy 1; if (HAL_UART_Transmit_DMA(handle-huart, handle-txBuf, len) ! HAL_OK) { handle-txBusy 0; return 1; } return 0; } void Uart_StartReceive(Uart_Handle *handle) { handle-rxNewData 0; handle-rxLen 0; HAL_UARTEx_ReceiveToIdle_DMA(handle-huart, handle-rxBuf, UART_BUF_SIZE); } void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { if (huart g_uart.huart) { g_uart.txBusy 0; } } void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart g_uart.huart) { g_uart.rxLen Size; g_uart.rxNewData 1; // 由主循环处理完数据后重新调用Uart_StartReceive } } int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART1_UART_Init(); MX_DMA_Init(); Uart_Init(g_uart, huart1); Uart_StartReceive(g_uart); uint8_t counter 0; while (1) { // 每500ms发送一次数据 uint16_t len sprintf((char *)testData, Hello STM32 DMA %d\r\n, counter); Uart_Send(g_uart, testData, len); HAL_Delay(500); // 如果收到数据就简单回显 if (g_uart.rxNewData) { Uart_Send(g_uart, g_uart.rxBuf, g_uart.rxLen); Uart_StartReceive(g_uart); } } }这套框架的核心思路是发送和接收都只登记一次DMA后续通过回调通知业务层。相比每发一次就调用一次HAL_UART_Transmit_DMA的写法对状态的把握更可控。你要做的就是根据实际需求把Uart_Send改造成“先入队、后发送”的形式或者把接收到的数据直接丢进环形缓冲区达到多包数据连续不间断处理的效果。实际使用这套框架时有几个点值得注意HAL_UARTEx_RxEventCallback里重新启动DMA接收的时机最好放到主循环而不是中断回调里避免接收缓冲被覆盖。如果你在中断里直接调Uart_StartReceive虽然临时也能用但一旦接收频率高竞争条件就会暴露。数据到来时主循环在检测到rxNewData后应当尽快把数据搬走否则下一包数据可能覆盖缓冲区。这个回显Demo比较粗糙真实项目中建议将“接收到的数据”和“要发送的数据”分开管理避免共用同一个缓冲导致互相覆盖。9. 写在最后的一点真心话串口DMA发送“只能发一次”这个坑我在刚接触HAL库时也踩过。当时折腾了整整一个晚上从怀疑DMA配置到怀疑芯片有问题最后发现只是DMA中断没有开启那种又气又笑的感觉到现在都记得。后来带团队带新人发现这个问题几乎成了HAL库入门必摔的一跤。所以我写这篇文章时特意把排查过程还原成了一套可以照做的步骤而不是直接丢一句“把中断勾上”就完事。我的个人建议是遇到这类异步外设问题不要急着改代码先静下心把HAL库的调用链捋清楚。HAL库虽然做了大量封装但它的状态机设计思路很一致无非就是“READY、BUSY、完成回调”这么几个阶段。你只有理解了gState、DMA中断、回调函数这三者之间的联动关系以后遇到ADC DMA、定时器DMA、SPI DMA的类似问题才能一眼看穿。比如“ADC只能采集一次”本质上和“串口DMA只能发一次”是同一个套路。最后再给你的建议开发阶段无论是CubeMX还是手写初始化都应该把调试器和逻辑分析仪准备齐全。有些问题单靠逻辑推断效率太低直接看寄存器、看波形几秒钟就有结论。能帮助你的不光是知识还有趁手的工具和足够的耐心。