我很少为一两个字节的问题专门写一篇分享但UART发送数据丢失最后一个字节这个坑我前前后后踩了不下三次每次还都是在不同的项目里以不同的面貌出现实在值得好好说道说道。这个问题在串口通信里太典型了典型的“看起来小、排查起来绕、知道原理后一分钟解决”。不管你是用STM32的HAL库还是标准外设库或者干脆直接操作寄存器甚至是在Linux下写串口应用只要涉及UART发送都有可能撞上它。先说清楚这篇文章能帮你解决什么彻底搞清楚“为什么最后一个字节总是丢”学会从硬件机制层面理解UART发送的完整流程拿到可以直接套用的解决方案和代码顺便收获一张排查速查表。适合正在被串口收发问题折磨的嵌入式开发新手也适合想系统梳理UART发送机制的老手。1. 问题现象与根因分析为什么偏偏是最后一个字节1.1 一个典型到不能再典型的现象描述先还原一下最常见的现场。你用STM32通过串口往外发一串数据代码逻辑大概是// 伪代码示意用 for (i 0; i len; i) { while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) RESET); USART_SendData(USART1, buffer[i]); }逻辑上看起来没有任何问题发送缓冲区非空就等待空了就填下一个字节。但你把逻辑分析仪接到TX引脚上一看或者用USB转TTL小板子收到电脑上对比发现发出去的数据总是少了最后一个字节。更气人的是这个现象不是每次都出现。波特率越高越容易出现数据量越大越容易出现有时候连续发几十次才出现一次有时候次次都丢。这种“间歇性Bug”最折磨人因为不好复现就不容易定位。我最早遇到这个现象时第一反应是检查波特率有没有配错因为波特率误差会导致接收端采样错位。但检查下来发现波特率没问题因为前面的字节都收得准准的。后来又怀疑是USB转TTL模块的兼容性问题换了好几个模块问题照旧。直到有一次把示波器探头直接点在TX引脚上才终于看到真相最后一个字节其实已经送进了移位寄存器正在往外一位一位地发但发送完成后引脚电平没有完全拉到位整个数据帧的停止位是残缺的接收端自然就判定这一帧无效丢弃了。1.2 硬件层面真正的根因TXE标志和TC标志的差别要真正弄明白这个问题得回到UART的硬件结构上。UART发送路径上有两个关键寄存器/标志位很多开发者在初级阶段只知其一不知其二。第一个是TXETransmit Data Register Empty发送数据寄存器空。你往数据寄存器DR里写一个字节硬件会把DR里的数据并行搬运到移位寄存器然后一位一位地串行发出去。DR被搬空之后TXE标志位置1表示“你可以往DR里写下一个字节了”。第二个是TCTransmission Complete发送完成。这个标志位要等到移位寄存器里的所有数据位、校验位、停止位全部发送完毕TX引脚回到空闲电平之后才会置1。问题就出在这里很多人的代码只等了TXE就认为发送完成了。TXE置1的时候你写的那个字节只是刚刚被搬进移位寄存器可能才发出去几位甚至还没开始发。如果你此时就把外设关了、把GPIO复用了、把时钟关了、进入了低功耗模式移位寄存器里剩下的那些位就会被硬生生掐断最后一字节自然就丢了。这就好比你在食堂打饭阿姨把菜从大锅里舀到你的餐盘里DR - 移位寄存器你觉得菜已经到手了转身就走结果阿姨最后一勺还在半空中没落到你盘子里你一转身那勺菜就掉地上了。TXE标志就是“菜已经舀起来了”TC标志才是“菜已经稳稳落进你盘子里”。1.3 软件层面常见的三个触发动作光知道TXE和TC的区别还不够还得知道实际代码里是哪些操作“掐断了”最后那个字节的发送。根据我的经验最常见的触发动作有三个。第一个是发送完后立刻操作外设。比如发送完一串AT指令后紧接着把串口切换到接收模式或者调用某个关闭串口的函数又或者把TX引脚重新配置成普通的GPIO。这些操作都可能在TC标志还没置位的时候把发送链路断掉。第二个是发送完后立刻进入低功耗模式。这在低功耗蓝牙、传感器节点、手持设备项目里特别常见。主控发完最后一帧数据觉得“活儿干完了”马上调用WFI或者进入STOP模式结果最后一个字节的停止位还没发完时钟一停数据就烂尾了。第三个是中断或者DMA的“提前收工”。用中断方式发送时最后一个字节触发的中断里做了收尾动作用DMA发送时DMA传输完成中断里关了UART或者清理了标志位。听起来都合理但实际执行顺序里有个隐蔽的时间窗口会导致最后一个字节没真正发完。2. 不同实现场景下的丢字节复盘我踩过的四种坑2.1 轮询发送场景等了TXE就开跑最基础也最常见的坑就是轮询方式只判断TXE。我早年在一个温湿度采集器项目里用STM32F103的标准外设库发数据代码就是最经典的那几行void UART_SendString(UART_TypeDef *UARTx, uint8_t *str, uint16_t len) { for (uint16_t i 0; i len; i) { while (USART_GetFlagStatus(UARTx, USART_FLAG_TXE) RESET); USART_SendData(UARTx, str[i]); } while (USART_GetFlagStatus(UARTx, USART_FLAG_TC) RESET); // 加了这个才稳 }当时以为循环结束后数据肯定发出去了结果上位机那边经常收不到完整帧。一开始我怀疑是上位机的接收缓冲问题后来用串口助手加时间戳一看每帧数据的末尾都缺一个字节。后来我查看了参考手册里关于TC标志的描述又用示波器对比了加不加while (USART_GetFlagStatus(UARTx, USART_FLAG_TC) RESET);这一行的波形差异才彻底确认问题就出在TXE和TC之间那个时间窗口上。这里有个细节值得多说一句如果你发完最后一个字节后紧接着还有其他对串口外设的操作比如清标志、关中断、改波特率那必须在这些操作之前保证TC已经置位。最简单粗暴的方式就是发送完最后一个字节后死等TC标志。2.2 中断发送场景最后一个字节进了移位寄存器中断却先收工了中断方式发送比轮询方式复杂一些丢字节的原因也更隐蔽。我做过一个用中断方式驱动SIM800模块发短信的项目。发送流程是先在主循环里把要发的内容放进一个环形缓冲区然后使能TXE中断让中断服务函数逐个把缓冲区里的字节写到DR寄存器。void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_TXE) ! RESET) { if (send_index send_len) { USART_SendData(USART1, send_buffer[send_index]); } else { USART_ITConfig(USART1, USART_IT_TXE, DISABLE); // 这里直接关了TXE中断但最后一个字节可能还在移位寄存器里 } } }问题就出在send_index send_len这个分支你只是把最后一个字节写进了DR它被搬到移位寄存器后TXE重新置1又触发了一次中断。但这时候你的发送索引已经用完了于是你直接关了TXE中断认为发送结束。实际上最后一个字节可能才刚进移位寄存器还没发完。虽然TXE中断关了不会影响移位寄存器继续发送——只要UART外设本身没有复位、时钟没有停它会老老实实把剩下的位发完——但如果此时主循环里有别的代码立刻操作了这个串口比如清标志位、重配置或者调用了USART_Cmd关闭外设那最后一个字节就悬了。更微妙的是如果此时另一个更高优先级的任务对UART外设做了任何写操作新的数据会把还没发完的旧数据顶掉。这种情况在实时操作系统里尤其容易出现。2.3 DMA发送场景传输完成并不等于发送完成DMA方式是丢最后一个字节的重灾区因为DMA有自己的“传输完成”概念它和UART的“发送完成”是两个完全不同的时刻。DMA负责把内存里的数据搬运到UART的DR寄存器。当DMA把最后一个字节写进DR它会立刻置位DMA传输完成标志。但此时UART的移位寄存器可能正在发送倒数第二个字节最后一个字节还只是待在DR里等着被搬进移位寄存器。很多人的DMA发送完成中断里是这样写的void DMA1_Channel4_IRQHandler(void) { if (DMA_GetITStatus(DMA1_IT_TC4)) { DMA_ClearITPendingBit(DMA1_IT_TC4); USART_DMACmd(USART1, USART_DMA_Req_TX, DISABLE); // 关闭UART的DMA发送请求 UART_TxDone 1; // 通知主循环发送完成 } }关闭UART的DMA发送请求这个操作本身不会掐断移位寄存器正在发送的字节但问题是如果主循环收到UART_TxDone 1的信号后立刻去操作UART外设——比如切换GPIO方向、重新配置串口参数、使能接收DMA——那最后一个字节就很容易丢。这里我要分享一个我自己的教训曾经在DMA发送完成中断里不仅关了DMA请求还顺手调用了USART_Cmd(USART1, DISABLE)去关闭UART外设想着省电。结果就是每次发送的最后一个字节都丢而且丢得很规律后来查了三天才在数据手册的一行小字里看到关闭USART外设会把当前正在发送的数据和移位寄存器里的数据都清掉。所以DMA发送的正确姿势是DMA传输完成中断里只关DMA请求不关UART外设然后等待UART的TC标志置位后再做后续操作。如果用的是支持“发送完成中断”的MCU可以直接开启UART的TC中断在TC中断里做收尾动作。2.4 低功耗场景发完最后一个字节就睡结果再也没醒过来这个场景在物联网设备里特别典型。设备通过UART上报数据上报完立刻进低功耗模式。我做过一个用NB-IoT模块上报数据的项目主控是STM32L151。代码逻辑大致是UART_SendString(ATQMTCFG\recv/mode\,0,0,1\r\n); UART_SendString(ATQMTCFG\recv/ind\,0,0,1\r\n); UART_SendString(ATQMTOPEN0,\iot.xxx.com\,1883\r\n); // ... 一系列AT指令 ... UART_SendString(ATQMTPUB0,0,0,0,\topic\,\hello\\r\n); // 发送完最后一串指令后立刻进低功耗 Enter_LowPower_Mode();现象是模块有时候能收到数据有时候收不到而且收不到的时候占大多数。用串口助手挂在TX和模块之间抓包发现每次“收不到”的情况都是最后一串AT指令的最后一个\r没有发出去或者发了一半就断了。原因就是最后一条指令发送完后立刻进了低功耗模式。虽然代码里发送函数用的是轮询方式并且等了TXE但并没有等TC。最后那个换行符可能还躺在移位寄存器里主控就熄灯睡觉了它自然就发不完整。这个场景的解决方案其实也很简单发送完最后一条数据后先原地等TC标志置位再进低功耗。有些MCU还提供了更优雅的做法比如开启UART的TC中断在TC中断里设置一个标志位主循环确认标志位后再进入低功耗确保“数据真的发完了”。3. 彻底解决从标准库到HAL库的完整方案对比3.1 方案一死等TC标志——最传统也最直接对于轮询发送方式最直接的解决方案就是发送完最后一个字节后等待TC标志置位。标准外设库的写法void UART_SendString_WaitTC(UART_TypeDef *UARTx, uint8_t *data, uint16_t len) { for (uint16_t i 0; i len; i) { // 等待DR寄存器为空 while (USART_GetFlagStatus(UARTx, USART_FLAG_TXE) RESET); USART_SendData(UARTx, data[i]); } // 关键等待最后一个字节完全发送完毕 while (USART_GetFlagStatus(UARTx, USART_FLAG_TC) RESET); }HAL库的写法更简单因为HAL_UART_Transmit内部已经处理了这个逻辑HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout) { // HAL库内部在发送完所有字节后会等待TC标志 // 具体代码在stm32f1xx_hal_uart.c里逻辑如下简化 while (huart-TxXferCount 0U) { // 等待TXE if (__HAL_UART_GET_FLAG(huart, UART_FLAG_TXE) RESET) { // 超时处理 } // 写DR huart-Instance-DR (*pData (uint8_t)0xFF); huart-TxXferCount--; } // 等待发送完成标志 while (__HAL_UART_GET_FLAG(huart, UART_FLAG_TC) RESET) { // 超时处理 } }如果你在用HAL库直接用HAL_UART_Transmit一般不会遇到丢最后一个字节的问题因为库已经帮你处理了TC等待。但如果你是在中断或者DMA模式下使用HAL库就得额外注意了。3.2 方案二DMA发送的完整正确姿势DMA方式的核心思路是DMA传输完成不等于UART发送完成发送完成要以UART的TC标志为准。用STM32标准库实现的一个标准流程// 发送前的准备 void UART_DMA_Send(uint8_t *data, uint16_t len) { // 等待上一次发送完全结束防止覆盖 while (uart_dma_busy); uart_dma_busy 1; // 填充DMA缓冲区和长度 DMA_SetCurrDataCounter(DMA1_Channel4, len); // 这里要确保DMA源地址正确指向要发送的数据 DMA_Config_Transfer(data, len); // 使能UART的DMA发送请求 USART_DMACmd(USART1, USART_DMA_Req_TX, ENABLE); // 使能DMA通道 DMA_Cmd(DMA1_Channel4, ENABLE); } // DMA传输完成中断 void DMA1_Channel4_IRQHandler(void) { if (DMA_GetITStatus(DMA1_IT_TC4)) { DMA_ClearITPendingBit(DMA1_IT_TC4); // 关闭UART的DMA请求但不关闭UART本身 USART_DMACmd(USART1, USART_DMA_Req_TX, DISABLE); // 使能UART的TC中断等待最后一个字节真正发完 USART_ITConfig(USART1, USART_IT_TC, ENABLE); } } // UART的TC中断 void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_TC) ! RESET) { USART_ClearITPendingBit(USART1, USART_IT_TC); USART_ITConfig(USART1, USART_IT_TC, DISABLE); uart_dma_busy 0; // 真正发送完成释放信号量 } }这套流程的关键点在于DMA中断只负责“数据已经从内存搬到UART的DR”后续的发送完成交给UART的TC中断来确认。如果你用的是STM32CubeMX生成的HAL库DMA代码那HAL_UART_Transmit_DMA这个函数其实不会自己等待TC它只负责启动DMA传输。你需要使用HAL_UART_TxCpltCallback回调函数并且在这个回调里等待TC标志。不过有个更巧妙的做法就是直接使用HAL_UART_Transmit_IT中断方式HAL库会在中断里自动处理TC等待。3.3 方案三清TC标志的必要性和正确位置还有一个容易被忽略的细节TC标志的清零时机。TC标志的置位条件是移位寄存器发送完成。如果你不清除TC标志下一次发送时你的等待TC循环会立即返回因为它看到的还是上次遗留的标志位。在标准库中清除TC标志的推荐做法是先读SR寄存器再写DR寄存器或者直接操作SR寄存器的TC位// 清除TC标志的两种方式 // 方式一读SR再写DR (void)USART_GetFlagStatus(USART1, USART_FLAG_TC); // 读SR USART_SendData(USART1, data); // 写DR // 方式二直接清TC位部分系列支持 USART_ClearFlag(USART1, USART_FLAG_TC);在HAL库里__HAL_UART_CLEAR_FLAG(huart, UART_FLAG_TC)可以直接用。实际操作中我的习惯是每次发送前先清一次TC标志然后再启动发送。这样不管上一次发送是什么状态结束的本次发送的TC等待一定能等到真正的“完成”时刻不会因为历史标志位的残留而误判。3.4 几种方案的选型建议不同场景适合不同方案我整理了一张选型对比表使用场景推荐方案说明简单轮询发送数据量小发送完死等TC实现简单最可靠但会阻塞CPU中断发送数据量为中等中断里处理TXE最后等TC不阻塞主循环但需要注意中断优先级DMA发送数据量大DMA TC中断联动效率最高但配置稍微复杂低功耗设备发送后立即睡眠发完等待TC再睡眠必须等TC否则数据必丢RTOS环境多任务并发互斥锁 等待TC注意多任务同时访问串口的竞争问题我自己在项目里的选择逻辑很简单如果数据量不大、也不频繁就用轮询加等TC简单可靠不出错如果数据量中等、涉及长帧传输就上DMA加TC中断如果有低功耗需求不管用哪种方式发送完成后都必须确认TC置位才能睡。4. 调试定位技巧与排查速查表4.1 用逻辑分析仪看波形的正确方法遇到UART丢数据问题第一反应应该是看波形而不是改代码碰运气。把逻辑分析仪的通道接到TX引脚上地线接好采样率设置成波特率的至少8倍以上。比如波特率是115200采样率至少要921600建议直接设置成1M或者2M波形会更清晰。然后发送一串有规律的数据比如0x55, 0xAA, 0x55, 0xAA这种交替的字节。0x55是010101010xAA是10101010这两种字节能让你在波形上清晰地看到每一位的电平变化如果发送不完整一眼就能看出哪一位缺失。我常用的一个验证套路是发送一串自定义数据比如0x01, 0x02, 0x03, 0x04, 0x05然后在波形上数停止位。正常的UART帧结构是起始位低电平 8个数据位 停止位高电平。如果最后一个字节只有起始位和部分数据位没有完整的停止位那基本可以确定是发送被提前中断了。有一个细节要注意逻辑分析仪的触发设置。如果设置成上升沿触发可能会漏掉起始位建议设置成下降沿触发也就是起始位的边沿这样能保证抓到完整帧。4.2 用串口助手和上位机辅助判断的几个技巧没有逻辑分析仪的情况也可以用串口助手加一些技巧来判断。第一种技巧是发送端发完数据后隔一小段时间再关闭串口或者进入低功耗。比如在发送函数末尾加一个delay_ms(1)如果加上延时后数据就完整了说明问题大概率就是发送未完成就进行了后续操作。第二种技巧是让发送端每隔一段时间重复发送同样的数据然后在上位机统计完整帧的比例。如果丢失率随着波特率升高而变高或者随着单次发送数据量增大而变高基本可以断定是发送完成时序问题。第三种技巧比较冷门把发送内容里加上帧尾校验比如CRC或者累加和。如果上位机收到的数据经常是“缺了最后一个字节导致校验失败”那定位起来就非常快。我后来在做协议设计时都会强制要求应用层加帧尾校验不只是为了数据完整性也是为了排查问题方便。4.3 UART丢最后一个字节排查速查表根据我多年踩坑经验整理一张速查表基本覆盖了各种可能性现象特征可能原因检查方向每次发送都丢最后一个字节发送后未等待TC就关闭外设或操作GPIO检查发送函数后面是否有其他代码偶发丢失最后一个字节发送完成后有其他中断或任务抢占了CPU检查是否在发送完成前进入了低功耗模式波特率越高丢得越频繁移位寄存器发送时间缩短TC等待被错过检查波特率配置是否正确只有DMA发送丢字节DMA传输完成中断里关闭了UART外设检查DMA中断里是否禁止了USART外设只有使用HAL库时丢字节中断方式或DMA方式的回调里处理不当检查HAL_UART_TxCpltCallback里是否有TC等待发送完后马上进睡眠丢字节进入低功耗模式太早检查睡眠前是否确保TC标志置位数据帧最后缺失停止位发送被硬件复位或外设关闭中断用示波器检查最后一位波形4.4 一个我自己写的小工具函数安全发送排查过太多次这个问题之后我习惯把“安全发送”封装成一个工具函数所有项目都用同一个模式从根上避免这个坑。/** * brief 安全发送确保所有字节都真正发出 * param huart UART句柄 * param data 数据指针 * param len 数据长度 * return 0成功-1失败 */ int UART_SafeTransmit(UART_HandleTypeDef *huart, uint8_t *data, uint16_t len) { // 方式一轮询发送HAL自带TC等待 if (HAL_UART_Transmit(huart, data, len, 1000) ! HAL_OK) { return -1; } // 方式二如果是自己用寄存器写的话一定要等TC // 最后再补一次显式TC确认双保险 while (__HAL_UART_GET_FLAG(huart, UART_FLAG_TC) RESET) { // 加超时保护防止死循环 static uint32_t tick 0; if (tick 100000) { return -1; } } return 0; }这个函数的核心思想就是不管底层用什么方式发送最后都要确认TC标志。尤其在低功耗设备上这个函数会作为进入睡眠前的最后一道关卡。5. 背后的硬件原理移位寄存器视角5.1 UART发送数据通路的完整过程要彻底根治这个问题最好还是把UART发送的完整链路在脑子里过一遍。我从数据手册和实际波形中总结了一个极简流程第一步CPU或DMA把一个字节写入UART的DR数据寄存器。这个写入动作本身不会直接触发发送而是把数据放在一个“待发缓冲区”里。第二步如果此时移位寄存器的准备工作已完成DR里的数据会被自动搬运到移位寄存器。同时TXE标志置位表示DR已经空了可以接收下一个字节。如果DR里已经有新数据但没有TXE置位那说明数据还没有被搬走写入操作会被阻塞或者覆盖具体取决于芯片设计。第三步移位寄存器按照配置的波特率把数据一位一位地移到TX引脚上先是起始位然后是8个数据位再是校验位可选最后是停止位。移位寄存器完全清空、TX引脚回到空闲高电平后TC标志置位。这里有一个很多初学者不清楚的细节DR只有一个字节深度的缓冲没有更深层的FIFO除非芯片专门标注。所以当DR里有数据、TXE没有置位时你再往DR里写数据会直接把之前没搬走的数据覆盖掉。这就是为什么写发送代码时要先等TXE再写DR。更深的机制是有些MCU会在“DR数据被搬运到移位寄存器”这个瞬间同时清除TXE标志表示DR已经在“占用中”。所以要养成习惯写DR前一定先检查TXE不要盲目往DR里灌数据。5.2 不同MCU系列的细节差异别拿F1的写法套F4不同MCU系列在UART发送的细节上可能会有细微差异尤其是标志位的定义和清除方式。STM32F1系列的USART算是最经典的它有一个SR状态寄存器TXE和TC都在里面。清除TC的推荐操作是“读SR后写DR”。这看起来有点反直觉但这是参考手册明确写的目的是防止误清除其他标志。STM32F4系列和F7系列在USART模块上做了一些改进寄存器结构有所调整。虽然TXE和TC的语义没变但有些系列增加了FIFO选项比如F7的UART模块支持FIFO模式在启用FIFO的情况下TXE标志的含义会略有不同它表示FIFO里还有空间可以写入多个字节而不是只是DR单缓冲。其他厂商的MCU比如NXP的LPC系列、TI的MSP430系列虽然UART模块叫的名字不同有的叫UART有的叫USCI有的叫eUSCI但底层的数据通路基本一致都是“数据寄存器 - 移位寄存器 - TX引脚”的结构。换句话说只要理解了“数据寄存器空”不等于“发送完成”这个核心就能应对几乎所有MCU的UART发送丢最后一个字节问题。5.3 波特率误差和最后一个字节的关系还有一个容易混淆的点我单独拎出来说清楚波特率误差一般不会导致只丢最后一个字节而是会导致整个数据帧里随机出现误码。如果你发现只有最后一个字节丢失而且丢的时候波形上停止位是完整的那大概率不是波特率问题还是“发送未完成就被打断”的问题。但有一种特殊情况当波特率误差较大时最后一个字节的停止位采样点可能刚好落在误码区间导致接收端判定“帧错误”。这种情况通常在数据帧很长时才会出现因为误差会累积越到后面的字节采样偏差越大。如果你发送的数据帧特别长比如一次发几百个字节最后一个字节的停止位采样出问题的概率确实会增加。解决这类问题的思路是尽量将波特率误差控制在2%以内选外部晶振而不是内部RC振荡器内部RC在高低温下误差可能超过3%接收端使用带自动波特率检测或帧错误恢复的UART外设。6. 从一次实际排障过程看完整思路6.1 现场情况一个锂电池BMS项目的真实案例去年做一个锂电池BMS从控板主控是STM32G030通过UART和上位机通信。现象是上位机偶尔收不到从控板上报的数据帧而且每次都缺最后一个字节。更诡异的是用USB转TTL模块单独接到从控板上测试时又不丢只有接上整个BMS系统时才丢。这个问题查了我整整两天。开始怀疑是电源纹波导致UART电平异常在TX引脚上加了滤波电容没用。后来怀疑是接地问题把各个板子的地重新接了一遍还是没用。再后来怀疑是上位机那边的串口接收线程处理太慢加了缓冲区依然没用。最后我用逻辑分析仪同时抓TX引脚和另一个干扰信号引脚的波形才发现每次丢字节的时候TX引脚的最后一个字节的停止位刚发到一半从控板的SPI Flash写入操作就开始了这个操作瞬间拉高了板载DC-DC的输出纹波导致TX引脚的电平被污染接收端判定停止位无效。6.2 怎么一步步缩小排查范围这次排障给我最大的启发是排查顺序很重要不要一上来就怀疑代码逻辑。第一步确认“最后一个字节丢了”是不是事实。用逻辑分析仪抓原始波形不要依赖上位机软件显示。上位机软件可能因为驱动、缓冲区等问题漏数据。第二步判断丢字节是发送端责任还是接收端责任。把发送端的TX引脚直接接到另一个独立的串口接收设备上如果独立设备也丢那问题在发送端如果独立设备不丢那问题在发送端和原接收端之间的环境干扰。第三步检查发送端的软件时序。在发送函数前后加几个GPIO翻转的调试引脚用逻辑分析仪同时抓GPIO和TX波形就能看出“发送完成”和“后续操作”之间的时间关系。如果后续操作比如SPI写入发生在TC标志置位之前那就有问题了。第四步检查硬件环境。这部分最容易忽视却往往是最坑的。电源纹波、地弹、长线传输、引脚驱动能力不足都可能表现为最后一个字节丢失。特别是在大电流设备旁边UART这种异步通信对电平质量还是比较敏感的。6.3 排障工具箱我常用的几种工具组合这里列一下我日常排查串口问题时的常用工具都是些常见设备没有昂贵仪器逻辑分析仪必备推荐8通道以上的采样率至少24M。几十块钱的“玩具级”逻辑分析仪就够用关键是软件要好用能把UART协议直接解码出来。USB转TTL模块多备几个不同方案的比如CH340、CP2102、FT232等。不同方案的驱动和电气特性有差异可以互相验证是不是模块问题。示波器逻辑分析仪看到的是“逻辑电平”示波器能看到真实的电压波形。如果怀疑信号质量有问题就得用示波器看上升沿、下降沿、过冲、振铃。串口调试助手推荐支持Hex显示和文件日志的能记录完整数据帧方便回放分析。这套工具组合下来一般串口问题都不会卡太久。核心思路就一个把“看不见的信号”变成“看得见的波形”一切以实测为准。7. 再往深做一步几个容易踩的延伸坑7.1 发送完成回调里做“太多事”导致的问题使用HAL库时HAL_UART_TxCpltCallback这个回调函数几乎是人人都会用但很多人会在这个回调里做额外操作比如更新状态、启动下一次发送、操作外设。这里有个隐患HAL库的HAL_UART_TxCpltCallback是在TC标志置位后才被调用的所以此时最后一个字节理论上已经发送完毕。但要注意这个回调是在中断上下文里执行的如果你在回调里执行了耗时操作比如软件延时、打印日志、操作I2C外设可能会阻塞中断处理带来其他时序问题。我见过一个很有趣的Bug有人在HAL_UART_TxCpltCallback里调用HAL_UART_Transmit发送另一条日志数据结果发生了递归中断数据发送完全错乱。这是因为HAL_UART_Transmit使用的是轮询等待但此时又处在中断上下文里如果UART的接收中断或者错误中断被触发就会造成嵌套混乱。在回调里应该做的是设置标志位、释放信号量、启动另一个异步操作比如DMA而不是做耗时的同步操作。7.2 多字节连续发送时的TXE处理一个常用的FIFO技巧当需要连续发送多个字节时如果每个字节都等一次TXE效率会比较低。尤其在高波特率下UART发送一个字节可能只需要几十微秒但CPU从“检测到TXE置位”到“写入DR”这个过程会有延迟如果延迟太长就会让TX引脚出现空闲期降低实际吞吐量。一个常用的优化技巧是在第一个字节写入DR后立刻循环检查TXE并写入下一个字节而不是每写一个字节都重新判断TXE。这样做的好处是当硬件把第一个字节从DR搬运到移位寄存器时TXE立即置位CPU可以马上写入下一个字节避免了“DR空着但CPU还没写”的空档期。这段优化后的代码大概是void UART_SendString_Fast(UART_TypeDef *UARTx, uint8_t *data, uint16_t len) { if (len 0) return; // 先写第一个字节 USART_SendData(UARTx, data[0]); // 再循环发送剩余字节 for (uint16_t i 1; i len; i) { while (USART_GetFlagStatus(UARTx, USART_FLAG_TXE) RESET); USART_SendData(UARTx, data[i]); } // 最后等待TC while (USART_GetFlagStatus(UARTx, USART_FLAG_TC) RESET); }但这个优化有个前提你必须确保DR的深度足够或者说你必须在TXE置位后尽快写入下一个字节。如果芯片的UART支持FIFO模式那可以利用FIFO深度来进一步减少CPU干预但底层逻辑依然不变必须等TC才能确认发送完成。7.3 为什么有些时候“丢最后一个字节”其实不是UART的问题最后说一个容易误判的情况。有时候你在上位机看到数据少了最后一个字节不一定就是发送端真的少发了也可能是接收端的处理问题。比如USB转TTL模块的驱动有缓存溢出问题当数据量很大时驱动缓冲区满了最后一个字节可能被丢弃。又比如上位机的串口接收程序用了固定长度的缓冲区一次性读取了N个字节但串口数据到达的时机有延迟导致最后一次读取只读到了前N-1个字节。判断方法很简单用逻辑分析仪直接抓TX引脚如果TX引脚上最后一个字节的波形是完整的那问题就在接收链路。如果波形不完整那才是发送端的事。还有种更隐蔽的情况有的USB转TTL模块在收到数据后会通过USB批量传输协议发给上位机这个过程中可能会因为USB的帧调度延迟导致数据“看起来”不完整但实际上数据是完整的只是到达时间有偏差。这种情况在高速率、大批量传输时尤其常见。我自己现在遇到“丢最后一个字节”这个问题第一反应是先上逻辑分析仪把发送端波形看清楚再下结论。这个习惯帮我避开了很多冤枉路。7.4 关于项目改造后的稳定性验证改完发送逻辑后不建议只测几个包没问题就收工。UART这种异步通信问题最容易在小概率、长时间运行后突然冒出来。我的习惯是跑一轮压力测试让设备连续发送至少10万帧数据上位机或者逻辑分析仪统计误码率、丢帧率并且至少覆盖波特率和数据长度的边界条件。比如你平时的波特率是9600那可以上下各测一档同时把单帧数据长度从1个字节到最大帧长都测一遍。因为不同长度下UART的TC等待时间不一样可能会暴露出新的时序窗口。实测下来这套方法配合前文的速查表基本能把UART发送侧的坑都踩平。另外说一句如果项目里用的MCU内部RC振荡器建议在做压力测试前先把系统时钟用外部晶振校准一遍。因为内部RC的精度受温度影响大如果系统时钟和UART波特率发生器本身就有偏差压力测试时很容易出现偶发的帧错误。这个坑我当年也踩过单独写出来提醒大家。 UART发送丢失最后一个字节？根因分析与解决方案详解
我很少为一两个字节的问题专门写一篇分享但UART发送数据丢失最后一个字节这个坑我前前后后踩了不下三次每次还都是在不同的项目里以不同的面貌出现实在值得好好说道说道。这个问题在串口通信里太典型了典型的“看起来小、排查起来绕、知道原理后一分钟解决”。不管你是用STM32的HAL库还是标准外设库或者干脆直接操作寄存器甚至是在Linux下写串口应用只要涉及UART发送都有可能撞上它。先说清楚这篇文章能帮你解决什么彻底搞清楚“为什么最后一个字节总是丢”学会从硬件机制层面理解UART发送的完整流程拿到可以直接套用的解决方案和代码顺便收获一张排查速查表。适合正在被串口收发问题折磨的嵌入式开发新手也适合想系统梳理UART发送机制的老手。1. 问题现象与根因分析为什么偏偏是最后一个字节1.1 一个典型到不能再典型的现象描述先还原一下最常见的现场。你用STM32通过串口往外发一串数据代码逻辑大概是// 伪代码示意用 for (i 0; i len; i) { while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) RESET); USART_SendData(USART1, buffer[i]); }逻辑上看起来没有任何问题发送缓冲区非空就等待空了就填下一个字节。但你把逻辑分析仪接到TX引脚上一看或者用USB转TTL小板子收到电脑上对比发现发出去的数据总是少了最后一个字节。更气人的是这个现象不是每次都出现。波特率越高越容易出现数据量越大越容易出现有时候连续发几十次才出现一次有时候次次都丢。这种“间歇性Bug”最折磨人因为不好复现就不容易定位。我最早遇到这个现象时第一反应是检查波特率有没有配错因为波特率误差会导致接收端采样错位。但检查下来发现波特率没问题因为前面的字节都收得准准的。后来又怀疑是USB转TTL模块的兼容性问题换了好几个模块问题照旧。直到有一次把示波器探头直接点在TX引脚上才终于看到真相最后一个字节其实已经送进了移位寄存器正在往外一位一位地发但发送完成后引脚电平没有完全拉到位整个数据帧的停止位是残缺的接收端自然就判定这一帧无效丢弃了。1.2 硬件层面真正的根因TXE标志和TC标志的差别要真正弄明白这个问题得回到UART的硬件结构上。UART发送路径上有两个关键寄存器/标志位很多开发者在初级阶段只知其一不知其二。第一个是TXETransmit Data Register Empty发送数据寄存器空。你往数据寄存器DR里写一个字节硬件会把DR里的数据并行搬运到移位寄存器然后一位一位地串行发出去。DR被搬空之后TXE标志位置1表示“你可以往DR里写下一个字节了”。第二个是TCTransmission Complete发送完成。这个标志位要等到移位寄存器里的所有数据位、校验位、停止位全部发送完毕TX引脚回到空闲电平之后才会置1。问题就出在这里很多人的代码只等了TXE就认为发送完成了。TXE置1的时候你写的那个字节只是刚刚被搬进移位寄存器可能才发出去几位甚至还没开始发。如果你此时就把外设关了、把GPIO复用了、把时钟关了、进入了低功耗模式移位寄存器里剩下的那些位就会被硬生生掐断最后一字节自然就丢了。这就好比你在食堂打饭阿姨把菜从大锅里舀到你的餐盘里DR - 移位寄存器你觉得菜已经到手了转身就走结果阿姨最后一勺还在半空中没落到你盘子里你一转身那勺菜就掉地上了。TXE标志就是“菜已经舀起来了”TC标志才是“菜已经稳稳落进你盘子里”。1.3 软件层面常见的三个触发动作光知道TXE和TC的区别还不够还得知道实际代码里是哪些操作“掐断了”最后那个字节的发送。根据我的经验最常见的触发动作有三个。第一个是发送完后立刻操作外设。比如发送完一串AT指令后紧接着把串口切换到接收模式或者调用某个关闭串口的函数又或者把TX引脚重新配置成普通的GPIO。这些操作都可能在TC标志还没置位的时候把发送链路断掉。第二个是发送完后立刻进入低功耗模式。这在低功耗蓝牙、传感器节点、手持设备项目里特别常见。主控发完最后一帧数据觉得“活儿干完了”马上调用WFI或者进入STOP模式结果最后一个字节的停止位还没发完时钟一停数据就烂尾了。第三个是中断或者DMA的“提前收工”。用中断方式发送时最后一个字节触发的中断里做了收尾动作用DMA发送时DMA传输完成中断里关了UART或者清理了标志位。听起来都合理但实际执行顺序里有个隐蔽的时间窗口会导致最后一个字节没真正发完。2. 不同实现场景下的丢字节复盘我踩过的四种坑2.1 轮询发送场景等了TXE就开跑最基础也最常见的坑就是轮询方式只判断TXE。我早年在一个温湿度采集器项目里用STM32F103的标准外设库发数据代码就是最经典的那几行void UART_SendString(UART_TypeDef *UARTx, uint8_t *str, uint16_t len) { for (uint16_t i 0; i len; i) { while (USART_GetFlagStatus(UARTx, USART_FLAG_TXE) RESET); USART_SendData(UARTx, str[i]); } while (USART_GetFlagStatus(UARTx, USART_FLAG_TC) RESET); // 加了这个才稳 }当时以为循环结束后数据肯定发出去了结果上位机那边经常收不到完整帧。一开始我怀疑是上位机的接收缓冲问题后来用串口助手加时间戳一看每帧数据的末尾都缺一个字节。后来我查看了参考手册里关于TC标志的描述又用示波器对比了加不加while (USART_GetFlagStatus(UARTx, USART_FLAG_TC) RESET);这一行的波形差异才彻底确认问题就出在TXE和TC之间那个时间窗口上。这里有个细节值得多说一句如果你发完最后一个字节后紧接着还有其他对串口外设的操作比如清标志、关中断、改波特率那必须在这些操作之前保证TC已经置位。最简单粗暴的方式就是发送完最后一个字节后死等TC标志。2.2 中断发送场景最后一个字节进了移位寄存器中断却先收工了中断方式发送比轮询方式复杂一些丢字节的原因也更隐蔽。我做过一个用中断方式驱动SIM800模块发短信的项目。发送流程是先在主循环里把要发的内容放进一个环形缓冲区然后使能TXE中断让中断服务函数逐个把缓冲区里的字节写到DR寄存器。void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_TXE) ! RESET) { if (send_index send_len) { USART_SendData(USART1, send_buffer[send_index]); } else { USART_ITConfig(USART1, USART_IT_TXE, DISABLE); // 这里直接关了TXE中断但最后一个字节可能还在移位寄存器里 } } }问题就出在send_index send_len这个分支你只是把最后一个字节写进了DR它被搬到移位寄存器后TXE重新置1又触发了一次中断。但这时候你的发送索引已经用完了于是你直接关了TXE中断认为发送结束。实际上最后一个字节可能才刚进移位寄存器还没发完。虽然TXE中断关了不会影响移位寄存器继续发送——只要UART外设本身没有复位、时钟没有停它会老老实实把剩下的位发完——但如果此时主循环里有别的代码立刻操作了这个串口比如清标志位、重配置或者调用了USART_Cmd关闭外设那最后一个字节就悬了。更微妙的是如果此时另一个更高优先级的任务对UART外设做了任何写操作新的数据会把还没发完的旧数据顶掉。这种情况在实时操作系统里尤其容易出现。2.3 DMA发送场景传输完成并不等于发送完成DMA方式是丢最后一个字节的重灾区因为DMA有自己的“传输完成”概念它和UART的“发送完成”是两个完全不同的时刻。DMA负责把内存里的数据搬运到UART的DR寄存器。当DMA把最后一个字节写进DR它会立刻置位DMA传输完成标志。但此时UART的移位寄存器可能正在发送倒数第二个字节最后一个字节还只是待在DR里等着被搬进移位寄存器。很多人的DMA发送完成中断里是这样写的void DMA1_Channel4_IRQHandler(void) { if (DMA_GetITStatus(DMA1_IT_TC4)) { DMA_ClearITPendingBit(DMA1_IT_TC4); USART_DMACmd(USART1, USART_DMA_Req_TX, DISABLE); // 关闭UART的DMA发送请求 UART_TxDone 1; // 通知主循环发送完成 } }关闭UART的DMA发送请求这个操作本身不会掐断移位寄存器正在发送的字节但问题是如果主循环收到UART_TxDone 1的信号后立刻去操作UART外设——比如切换GPIO方向、重新配置串口参数、使能接收DMA——那最后一个字节就很容易丢。这里我要分享一个我自己的教训曾经在DMA发送完成中断里不仅关了DMA请求还顺手调用了USART_Cmd(USART1, DISABLE)去关闭UART外设想着省电。结果就是每次发送的最后一个字节都丢而且丢得很规律后来查了三天才在数据手册的一行小字里看到关闭USART外设会把当前正在发送的数据和移位寄存器里的数据都清掉。所以DMA发送的正确姿势是DMA传输完成中断里只关DMA请求不关UART外设然后等待UART的TC标志置位后再做后续操作。如果用的是支持“发送完成中断”的MCU可以直接开启UART的TC中断在TC中断里做收尾动作。2.4 低功耗场景发完最后一个字节就睡结果再也没醒过来这个场景在物联网设备里特别典型。设备通过UART上报数据上报完立刻进低功耗模式。我做过一个用NB-IoT模块上报数据的项目主控是STM32L151。代码逻辑大致是UART_SendString(ATQMTCFG\recv/mode\,0,0,1\r\n); UART_SendString(ATQMTCFG\recv/ind\,0,0,1\r\n); UART_SendString(ATQMTOPEN0,\iot.xxx.com\,1883\r\n); // ... 一系列AT指令 ... UART_SendString(ATQMTPUB0,0,0,0,\topic\,\hello\\r\n); // 发送完最后一串指令后立刻进低功耗 Enter_LowPower_Mode();现象是模块有时候能收到数据有时候收不到而且收不到的时候占大多数。用串口助手挂在TX和模块之间抓包发现每次“收不到”的情况都是最后一串AT指令的最后一个\r没有发出去或者发了一半就断了。原因就是最后一条指令发送完后立刻进了低功耗模式。虽然代码里发送函数用的是轮询方式并且等了TXE但并没有等TC。最后那个换行符可能还躺在移位寄存器里主控就熄灯睡觉了它自然就发不完整。这个场景的解决方案其实也很简单发送完最后一条数据后先原地等TC标志置位再进低功耗。有些MCU还提供了更优雅的做法比如开启UART的TC中断在TC中断里设置一个标志位主循环确认标志位后再进入低功耗确保“数据真的发完了”。3. 彻底解决从标准库到HAL库的完整方案对比3.1 方案一死等TC标志——最传统也最直接对于轮询发送方式最直接的解决方案就是发送完最后一个字节后等待TC标志置位。标准外设库的写法void UART_SendString_WaitTC(UART_TypeDef *UARTx, uint8_t *data, uint16_t len) { for (uint16_t i 0; i len; i) { // 等待DR寄存器为空 while (USART_GetFlagStatus(UARTx, USART_FLAG_TXE) RESET); USART_SendData(UARTx, data[i]); } // 关键等待最后一个字节完全发送完毕 while (USART_GetFlagStatus(UARTx, USART_FLAG_TC) RESET); }HAL库的写法更简单因为HAL_UART_Transmit内部已经处理了这个逻辑HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout) { // HAL库内部在发送完所有字节后会等待TC标志 // 具体代码在stm32f1xx_hal_uart.c里逻辑如下简化 while (huart-TxXferCount 0U) { // 等待TXE if (__HAL_UART_GET_FLAG(huart, UART_FLAG_TXE) RESET) { // 超时处理 } // 写DR huart-Instance-DR (*pData (uint8_t)0xFF); huart-TxXferCount--; } // 等待发送完成标志 while (__HAL_UART_GET_FLAG(huart, UART_FLAG_TC) RESET) { // 超时处理 } }如果你在用HAL库直接用HAL_UART_Transmit一般不会遇到丢最后一个字节的问题因为库已经帮你处理了TC等待。但如果你是在中断或者DMA模式下使用HAL库就得额外注意了。3.2 方案二DMA发送的完整正确姿势DMA方式的核心思路是DMA传输完成不等于UART发送完成发送完成要以UART的TC标志为准。用STM32标准库实现的一个标准流程// 发送前的准备 void UART_DMA_Send(uint8_t *data, uint16_t len) { // 等待上一次发送完全结束防止覆盖 while (uart_dma_busy); uart_dma_busy 1; // 填充DMA缓冲区和长度 DMA_SetCurrDataCounter(DMA1_Channel4, len); // 这里要确保DMA源地址正确指向要发送的数据 DMA_Config_Transfer(data, len); // 使能UART的DMA发送请求 USART_DMACmd(USART1, USART_DMA_Req_TX, ENABLE); // 使能DMA通道 DMA_Cmd(DMA1_Channel4, ENABLE); } // DMA传输完成中断 void DMA1_Channel4_IRQHandler(void) { if (DMA_GetITStatus(DMA1_IT_TC4)) { DMA_ClearITPendingBit(DMA1_IT_TC4); // 关闭UART的DMA请求但不关闭UART本身 USART_DMACmd(USART1, USART_DMA_Req_TX, DISABLE); // 使能UART的TC中断等待最后一个字节真正发完 USART_ITConfig(USART1, USART_IT_TC, ENABLE); } } // UART的TC中断 void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_TC) ! RESET) { USART_ClearITPendingBit(USART1, USART_IT_TC); USART_ITConfig(USART1, USART_IT_TC, DISABLE); uart_dma_busy 0; // 真正发送完成释放信号量 } }这套流程的关键点在于DMA中断只负责“数据已经从内存搬到UART的DR”后续的发送完成交给UART的TC中断来确认。如果你用的是STM32CubeMX生成的HAL库DMA代码那HAL_UART_Transmit_DMA这个函数其实不会自己等待TC它只负责启动DMA传输。你需要使用HAL_UART_TxCpltCallback回调函数并且在这个回调里等待TC标志。不过有个更巧妙的做法就是直接使用HAL_UART_Transmit_IT中断方式HAL库会在中断里自动处理TC等待。3.3 方案三清TC标志的必要性和正确位置还有一个容易被忽略的细节TC标志的清零时机。TC标志的置位条件是移位寄存器发送完成。如果你不清除TC标志下一次发送时你的等待TC循环会立即返回因为它看到的还是上次遗留的标志位。在标准库中清除TC标志的推荐做法是先读SR寄存器再写DR寄存器或者直接操作SR寄存器的TC位// 清除TC标志的两种方式 // 方式一读SR再写DR (void)USART_GetFlagStatus(USART1, USART_FLAG_TC); // 读SR USART_SendData(USART1, data); // 写DR // 方式二直接清TC位部分系列支持 USART_ClearFlag(USART1, USART_FLAG_TC);在HAL库里__HAL_UART_CLEAR_FLAG(huart, UART_FLAG_TC)可以直接用。实际操作中我的习惯是每次发送前先清一次TC标志然后再启动发送。这样不管上一次发送是什么状态结束的本次发送的TC等待一定能等到真正的“完成”时刻不会因为历史标志位的残留而误判。3.4 几种方案的选型建议不同场景适合不同方案我整理了一张选型对比表使用场景推荐方案说明简单轮询发送数据量小发送完死等TC实现简单最可靠但会阻塞CPU中断发送数据量为中等中断里处理TXE最后等TC不阻塞主循环但需要注意中断优先级DMA发送数据量大DMA TC中断联动效率最高但配置稍微复杂低功耗设备发送后立即睡眠发完等待TC再睡眠必须等TC否则数据必丢RTOS环境多任务并发互斥锁 等待TC注意多任务同时访问串口的竞争问题我自己在项目里的选择逻辑很简单如果数据量不大、也不频繁就用轮询加等TC简单可靠不出错如果数据量中等、涉及长帧传输就上DMA加TC中断如果有低功耗需求不管用哪种方式发送完成后都必须确认TC置位才能睡。4. 调试定位技巧与排查速查表4.1 用逻辑分析仪看波形的正确方法遇到UART丢数据问题第一反应应该是看波形而不是改代码碰运气。把逻辑分析仪的通道接到TX引脚上地线接好采样率设置成波特率的至少8倍以上。比如波特率是115200采样率至少要921600建议直接设置成1M或者2M波形会更清晰。然后发送一串有规律的数据比如0x55, 0xAA, 0x55, 0xAA这种交替的字节。0x55是010101010xAA是10101010这两种字节能让你在波形上清晰地看到每一位的电平变化如果发送不完整一眼就能看出哪一位缺失。我常用的一个验证套路是发送一串自定义数据比如0x01, 0x02, 0x03, 0x04, 0x05然后在波形上数停止位。正常的UART帧结构是起始位低电平 8个数据位 停止位高电平。如果最后一个字节只有起始位和部分数据位没有完整的停止位那基本可以确定是发送被提前中断了。有一个细节要注意逻辑分析仪的触发设置。如果设置成上升沿触发可能会漏掉起始位建议设置成下降沿触发也就是起始位的边沿这样能保证抓到完整帧。4.2 用串口助手和上位机辅助判断的几个技巧没有逻辑分析仪的情况也可以用串口助手加一些技巧来判断。第一种技巧是发送端发完数据后隔一小段时间再关闭串口或者进入低功耗。比如在发送函数末尾加一个delay_ms(1)如果加上延时后数据就完整了说明问题大概率就是发送未完成就进行了后续操作。第二种技巧是让发送端每隔一段时间重复发送同样的数据然后在上位机统计完整帧的比例。如果丢失率随着波特率升高而变高或者随着单次发送数据量增大而变高基本可以断定是发送完成时序问题。第三种技巧比较冷门把发送内容里加上帧尾校验比如CRC或者累加和。如果上位机收到的数据经常是“缺了最后一个字节导致校验失败”那定位起来就非常快。我后来在做协议设计时都会强制要求应用层加帧尾校验不只是为了数据完整性也是为了排查问题方便。4.3 UART丢最后一个字节排查速查表根据我多年踩坑经验整理一张速查表基本覆盖了各种可能性现象特征可能原因检查方向每次发送都丢最后一个字节发送后未等待TC就关闭外设或操作GPIO检查发送函数后面是否有其他代码偶发丢失最后一个字节发送完成后有其他中断或任务抢占了CPU检查是否在发送完成前进入了低功耗模式波特率越高丢得越频繁移位寄存器发送时间缩短TC等待被错过检查波特率配置是否正确只有DMA发送丢字节DMA传输完成中断里关闭了UART外设检查DMA中断里是否禁止了USART外设只有使用HAL库时丢字节中断方式或DMA方式的回调里处理不当检查HAL_UART_TxCpltCallback里是否有TC等待发送完后马上进睡眠丢字节进入低功耗模式太早检查睡眠前是否确保TC标志置位数据帧最后缺失停止位发送被硬件复位或外设关闭中断用示波器检查最后一位波形4.4 一个我自己写的小工具函数安全发送排查过太多次这个问题之后我习惯把“安全发送”封装成一个工具函数所有项目都用同一个模式从根上避免这个坑。/** * brief 安全发送确保所有字节都真正发出 * param huart UART句柄 * param data 数据指针 * param len 数据长度 * return 0成功-1失败 */ int UART_SafeTransmit(UART_HandleTypeDef *huart, uint8_t *data, uint16_t len) { // 方式一轮询发送HAL自带TC等待 if (HAL_UART_Transmit(huart, data, len, 1000) ! HAL_OK) { return -1; } // 方式二如果是自己用寄存器写的话一定要等TC // 最后再补一次显式TC确认双保险 while (__HAL_UART_GET_FLAG(huart, UART_FLAG_TC) RESET) { // 加超时保护防止死循环 static uint32_t tick 0; if (tick 100000) { return -1; } } return 0; }这个函数的核心思想就是不管底层用什么方式发送最后都要确认TC标志。尤其在低功耗设备上这个函数会作为进入睡眠前的最后一道关卡。5. 背后的硬件原理移位寄存器视角5.1 UART发送数据通路的完整过程要彻底根治这个问题最好还是把UART发送的完整链路在脑子里过一遍。我从数据手册和实际波形中总结了一个极简流程第一步CPU或DMA把一个字节写入UART的DR数据寄存器。这个写入动作本身不会直接触发发送而是把数据放在一个“待发缓冲区”里。第二步如果此时移位寄存器的准备工作已完成DR里的数据会被自动搬运到移位寄存器。同时TXE标志置位表示DR已经空了可以接收下一个字节。如果DR里已经有新数据但没有TXE置位那说明数据还没有被搬走写入操作会被阻塞或者覆盖具体取决于芯片设计。第三步移位寄存器按照配置的波特率把数据一位一位地移到TX引脚上先是起始位然后是8个数据位再是校验位可选最后是停止位。移位寄存器完全清空、TX引脚回到空闲高电平后TC标志置位。这里有一个很多初学者不清楚的细节DR只有一个字节深度的缓冲没有更深层的FIFO除非芯片专门标注。所以当DR里有数据、TXE没有置位时你再往DR里写数据会直接把之前没搬走的数据覆盖掉。这就是为什么写发送代码时要先等TXE再写DR。更深的机制是有些MCU会在“DR数据被搬运到移位寄存器”这个瞬间同时清除TXE标志表示DR已经在“占用中”。所以要养成习惯写DR前一定先检查TXE不要盲目往DR里灌数据。5.2 不同MCU系列的细节差异别拿F1的写法套F4不同MCU系列在UART发送的细节上可能会有细微差异尤其是标志位的定义和清除方式。STM32F1系列的USART算是最经典的它有一个SR状态寄存器TXE和TC都在里面。清除TC的推荐操作是“读SR后写DR”。这看起来有点反直觉但这是参考手册明确写的目的是防止误清除其他标志。STM32F4系列和F7系列在USART模块上做了一些改进寄存器结构有所调整。虽然TXE和TC的语义没变但有些系列增加了FIFO选项比如F7的UART模块支持FIFO模式在启用FIFO的情况下TXE标志的含义会略有不同它表示FIFO里还有空间可以写入多个字节而不是只是DR单缓冲。其他厂商的MCU比如NXP的LPC系列、TI的MSP430系列虽然UART模块叫的名字不同有的叫UART有的叫USCI有的叫eUSCI但底层的数据通路基本一致都是“数据寄存器 - 移位寄存器 - TX引脚”的结构。换句话说只要理解了“数据寄存器空”不等于“发送完成”这个核心就能应对几乎所有MCU的UART发送丢最后一个字节问题。5.3 波特率误差和最后一个字节的关系还有一个容易混淆的点我单独拎出来说清楚波特率误差一般不会导致只丢最后一个字节而是会导致整个数据帧里随机出现误码。如果你发现只有最后一个字节丢失而且丢的时候波形上停止位是完整的那大概率不是波特率问题还是“发送未完成就被打断”的问题。但有一种特殊情况当波特率误差较大时最后一个字节的停止位采样点可能刚好落在误码区间导致接收端判定“帧错误”。这种情况通常在数据帧很长时才会出现因为误差会累积越到后面的字节采样偏差越大。如果你发送的数据帧特别长比如一次发几百个字节最后一个字节的停止位采样出问题的概率确实会增加。解决这类问题的思路是尽量将波特率误差控制在2%以内选外部晶振而不是内部RC振荡器内部RC在高低温下误差可能超过3%接收端使用带自动波特率检测或帧错误恢复的UART外设。6. 从一次实际排障过程看完整思路6.1 现场情况一个锂电池BMS项目的真实案例去年做一个锂电池BMS从控板主控是STM32G030通过UART和上位机通信。现象是上位机偶尔收不到从控板上报的数据帧而且每次都缺最后一个字节。更诡异的是用USB转TTL模块单独接到从控板上测试时又不丢只有接上整个BMS系统时才丢。这个问题查了我整整两天。开始怀疑是电源纹波导致UART电平异常在TX引脚上加了滤波电容没用。后来怀疑是接地问题把各个板子的地重新接了一遍还是没用。再后来怀疑是上位机那边的串口接收线程处理太慢加了缓冲区依然没用。最后我用逻辑分析仪同时抓TX引脚和另一个干扰信号引脚的波形才发现每次丢字节的时候TX引脚的最后一个字节的停止位刚发到一半从控板的SPI Flash写入操作就开始了这个操作瞬间拉高了板载DC-DC的输出纹波导致TX引脚的电平被污染接收端判定停止位无效。6.2 怎么一步步缩小排查范围这次排障给我最大的启发是排查顺序很重要不要一上来就怀疑代码逻辑。第一步确认“最后一个字节丢了”是不是事实。用逻辑分析仪抓原始波形不要依赖上位机软件显示。上位机软件可能因为驱动、缓冲区等问题漏数据。第二步判断丢字节是发送端责任还是接收端责任。把发送端的TX引脚直接接到另一个独立的串口接收设备上如果独立设备也丢那问题在发送端如果独立设备不丢那问题在发送端和原接收端之间的环境干扰。第三步检查发送端的软件时序。在发送函数前后加几个GPIO翻转的调试引脚用逻辑分析仪同时抓GPIO和TX波形就能看出“发送完成”和“后续操作”之间的时间关系。如果后续操作比如SPI写入发生在TC标志置位之前那就有问题了。第四步检查硬件环境。这部分最容易忽视却往往是最坑的。电源纹波、地弹、长线传输、引脚驱动能力不足都可能表现为最后一个字节丢失。特别是在大电流设备旁边UART这种异步通信对电平质量还是比较敏感的。6.3 排障工具箱我常用的几种工具组合这里列一下我日常排查串口问题时的常用工具都是些常见设备没有昂贵仪器逻辑分析仪必备推荐8通道以上的采样率至少24M。几十块钱的“玩具级”逻辑分析仪就够用关键是软件要好用能把UART协议直接解码出来。USB转TTL模块多备几个不同方案的比如CH340、CP2102、FT232等。不同方案的驱动和电气特性有差异可以互相验证是不是模块问题。示波器逻辑分析仪看到的是“逻辑电平”示波器能看到真实的电压波形。如果怀疑信号质量有问题就得用示波器看上升沿、下降沿、过冲、振铃。串口调试助手推荐支持Hex显示和文件日志的能记录完整数据帧方便回放分析。这套工具组合下来一般串口问题都不会卡太久。核心思路就一个把“看不见的信号”变成“看得见的波形”一切以实测为准。7. 再往深做一步几个容易踩的延伸坑7.1 发送完成回调里做“太多事”导致的问题使用HAL库时HAL_UART_TxCpltCallback这个回调函数几乎是人人都会用但很多人会在这个回调里做额外操作比如更新状态、启动下一次发送、操作外设。这里有个隐患HAL库的HAL_UART_TxCpltCallback是在TC标志置位后才被调用的所以此时最后一个字节理论上已经发送完毕。但要注意这个回调是在中断上下文里执行的如果你在回调里执行了耗时操作比如软件延时、打印日志、操作I2C外设可能会阻塞中断处理带来其他时序问题。我见过一个很有趣的Bug有人在HAL_UART_TxCpltCallback里调用HAL_UART_Transmit发送另一条日志数据结果发生了递归中断数据发送完全错乱。这是因为HAL_UART_Transmit使用的是轮询等待但此时又处在中断上下文里如果UART的接收中断或者错误中断被触发就会造成嵌套混乱。在回调里应该做的是设置标志位、释放信号量、启动另一个异步操作比如DMA而不是做耗时的同步操作。7.2 多字节连续发送时的TXE处理一个常用的FIFO技巧当需要连续发送多个字节时如果每个字节都等一次TXE效率会比较低。尤其在高波特率下UART发送一个字节可能只需要几十微秒但CPU从“检测到TXE置位”到“写入DR”这个过程会有延迟如果延迟太长就会让TX引脚出现空闲期降低实际吞吐量。一个常用的优化技巧是在第一个字节写入DR后立刻循环检查TXE并写入下一个字节而不是每写一个字节都重新判断TXE。这样做的好处是当硬件把第一个字节从DR搬运到移位寄存器时TXE立即置位CPU可以马上写入下一个字节避免了“DR空着但CPU还没写”的空档期。这段优化后的代码大概是void UART_SendString_Fast(UART_TypeDef *UARTx, uint8_t *data, uint16_t len) { if (len 0) return; // 先写第一个字节 USART_SendData(UARTx, data[0]); // 再循环发送剩余字节 for (uint16_t i 1; i len; i) { while (USART_GetFlagStatus(UARTx, USART_FLAG_TXE) RESET); USART_SendData(UARTx, data[i]); } // 最后等待TC while (USART_GetFlagStatus(UARTx, USART_FLAG_TC) RESET); }但这个优化有个前提你必须确保DR的深度足够或者说你必须在TXE置位后尽快写入下一个字节。如果芯片的UART支持FIFO模式那可以利用FIFO深度来进一步减少CPU干预但底层逻辑依然不变必须等TC才能确认发送完成。7.3 为什么有些时候“丢最后一个字节”其实不是UART的问题最后说一个容易误判的情况。有时候你在上位机看到数据少了最后一个字节不一定就是发送端真的少发了也可能是接收端的处理问题。比如USB转TTL模块的驱动有缓存溢出问题当数据量很大时驱动缓冲区满了最后一个字节可能被丢弃。又比如上位机的串口接收程序用了固定长度的缓冲区一次性读取了N个字节但串口数据到达的时机有延迟导致最后一次读取只读到了前N-1个字节。判断方法很简单用逻辑分析仪直接抓TX引脚如果TX引脚上最后一个字节的波形是完整的那问题就在接收链路。如果波形不完整那才是发送端的事。还有种更隐蔽的情况有的USB转TTL模块在收到数据后会通过USB批量传输协议发给上位机这个过程中可能会因为USB的帧调度延迟导致数据“看起来”不完整但实际上数据是完整的只是到达时间有偏差。这种情况在高速率、大批量传输时尤其常见。我自己现在遇到“丢最后一个字节”这个问题第一反应是先上逻辑分析仪把发送端波形看清楚再下结论。这个习惯帮我避开了很多冤枉路。7.4 关于项目改造后的稳定性验证改完发送逻辑后不建议只测几个包没问题就收工。UART这种异步通信问题最容易在小概率、长时间运行后突然冒出来。我的习惯是跑一轮压力测试让设备连续发送至少10万帧数据上位机或者逻辑分析仪统计误码率、丢帧率并且至少覆盖波特率和数据长度的边界条件。比如你平时的波特率是9600那可以上下各测一档同时把单帧数据长度从1个字节到最大帧长都测一遍。因为不同长度下UART的TC等待时间不一样可能会暴露出新的时序窗口。实测下来这套方法配合前文的速查表基本能把UART发送侧的坑都踩平。另外说一句如果项目里用的MCU内部RC振荡器建议在做压力测试前先把系统时钟用外部晶振校准一遍。因为内部RC的精度受温度影响大如果系统时钟和UART波特率发生器本身就有偏差压力测试时很容易出现偶发的帧错误。这个坑我当年也踩过单独写出来提醒大家。