摘要：在 `HAL_UART_Receive_DMA()` 模式下，串口帧错误或噪声错误可能让 HAL 结束接收却不自动恢复，结果是通信口看起来还在，实际上已经永远收不到数据。

这篇文章复盘一个在产线和现场环境里都很常见的串口问题：设备看起来正常运行，心跳还在，任务也没崩，但 HMI 或上位机命令完全无响应。根因不是协议，而是 HAL 在 UART 错误后悄悄停掉了 DMA 接收。

UART DMA 为什么会“静默死亡”：一次噪声就让接收口永久失联

串口问题最讨厌的一种，不是彻底挂死，而是“像活着一样地死掉”。

设备还在跑，心跳还在闪，主循环和任务调度也都正常，可上位机发过去的命令就是没有回音。你以为是线松了、干扰大、协议错了，最后发现根因藏在 HAL 的默认错误处理里。

现场现象

问题最早出现在带串口屏的人机接口链路上，设备在现场运行一段时间后，突然出现下面这些表现：

串口命令无响应
本地逻辑和定时任务还在继续执行
指示灯和继电器动作都正常
重启后恢复，但过一阵又会复发

这类现象很容易把人带偏。因为它不像“系统死机”，更像“外部通信偶发异常”。

如果只从表面看，常见怀疑对象会是：

上位机程序发错了帧
线缆接触不良
RS232/RS485 收发器偶发失步
某一帧数据把协议状态机打乱了

这些方向都不算错，但还没到根上。

根因：HAL 在出错后把接收停了，却不帮你拉起来

在 HAL_UART_Receive_DMA() 模式下，HAL 对接收错误的默认处理大致是：

void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart)
{
    if (huart->RxState == HAL_UART_STATE_BUSY_RX) {
        UART_EndRxTransfer(huart);
        /* 结束当前接收 */
        /* 不自动恢复 DMA */
    }
}

一旦出现这些错误中的任意一种：

帧错误
噪声错误
溢出错误

HAL 可能就会结束当前接收流程。关键在于，默认路径通常不会替你自动重启 DMA。

于是现场就变成了这样：

UART 出现一次物理层干扰
HAL 进入错误回调
DMA 接收被结束
后续没有重新启动接收
通信口从此“活着但收不到”

系统本身没有崩，所以它会继续执行其它任务。这就是为什么现场会误判成“上位机偶尔发不通”。

为什么这个问题会特别隐蔽

1. 故障只打断通信，不打断主程序

如果是 HardFault，至少你知道系统死了。这个问题更坏，它只让接收口失效，整机其余部分仍然在继续运行。

2. 复位后恢复，容易被当成偶发干扰

只要重启一切恢复正常，团队就很容易把它归类成“电气环境不好”。但如果不补自动恢复逻辑，下次还会再来。

3. HAL 默认行为对业务层并不友好

从库设计角度看，“出错后结束当前接收，等上层决定怎么处理”并不算错误；但从设备工程角度看，如果上层没有显式补救，这就是一个会让端口永久失联的坑。

更稳妥的修复思路

直接的修复办法，是在错误回调里明确做恢复，而不是指望 HAL 自动处理。

典型做法如下：

void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart)
{
    if (huart->Instance == USART1) {
        HAL_UART_DMAStop(huart);
        __HAL_UART_CLEAR_FEFLAG(huart);
        __HAL_UART_CLEAR_NEFLAG(huart);
        __HAL_UART_CLEAR_OREFLAG(huart);
        HAL_UART_Receive_DMA(huart, rx_buf, RX_BUF_SIZE);
    }
}

如果项目里用的是 DMA + IDLE 收包模型，还应该一起检查：