你遇到过串口死机吗
项目场景：
使用STM32L0单片机主频设定2.097M，使用LPUART，115200波特率的串口进行通信，会出现偶发性的串口死机现象。
问题描述
1.串口配置
2.回调函数接收数据
理论上通过以上配置，可以正常接收到DMA收到的不定长数据，经简单测试，每次通过串口助手，手动发送数据，确实都能正常接收并处理。
但是，一旦发送数据帧的周期太快，或者发送的数据量超过20个字节后，串口就很容易出现死机的现象。
通过进入仿真发现，暴力发送数据后，不会再进入中断。把数据解析函数屏蔽掉以后，再进入仿真，进行同样的测试，每次又都能进入中断。
通过比较两次的仿真，发现ISR中断状态寄存器ORE标志位被置位后，不会再进入中断。
原因分析：
查阅数据手册：
这个ORE的检测是CubeMX默认打开的，在UART的配置里面，如下：
产生中断和状态寄存器：
**Interrupt & status register (LPUART_ISR)**
清除中断和状态寄存器：
**Interrupt flag clear register (LPUART_ICR)**
通过以上数据手册中内容可知，ORE标志位置位后，必须通过ORECF寄存器清除ORE，否则接收不到新数据。
分析HAL库的代码发现： 发生溢出错误后，HAL_UART_IRQHandler，经过了三个步骤： 1.清除ORE标志位 2.关闭串口接收 3.调用错误回调函数
void HAL_UART_IRQHandler(UART_HandleTypeDef *huart)
{
uint32_t isrflags = READ_REG(huart->Instance->ISR);
uint32_t cr1its = READ_REG(huart->Instance->CR1);
uint32_t cr3its = READ_REG(huart->Instance->CR3);
uint32_t errorflags;
uint32_t errorcode;
/* If some errors occur */
if ((errorflags != 0U)
&& (((cr3its & USART_CR3_EIE) != 0U)
|| ((cr1its & (USART_CR1_RXNEIE | USART_CR1_PEIE | USART_CR1_RTOIE)) != 0U)))
{
/* UART Over-Run interrupt occurred -----------------------------------------*/
if (((isrflags & USART_ISR_ORE) != 0U)
&& (((cr1its & USART_CR1_RXNEIE) != 0U) ||
((cr3its & USART_CR3_EIE) != 0U)))
{
__HAL_UART_CLEAR_FLAG(huart, UART_CLEAR_OREF);//1.清除ORE标志位
huart->ErrorCode |= HAL_UART_ERROR_ORE;
}
/* If Error is to be considered as blocking :
- Receiver Timeout error in Reception
- Overrun error in Reception
- any error occurs in DMA mode reception
*/
errorcode = huart->ErrorCode;
if ((HAL_IS_BIT_SET(huart->Instance->CR3, USART_CR3_DMAR)) ||
((errorcode & (HAL_UART_ERROR_RTO | HAL_UART_ERROR_ORE)) != 0U))
{
/* Blocking error : transfer is aborted
Set the UART state ready to be able to start again the process,
Disable Rx Interrupts, and disable Rx DMA request, if ongoing */
UART_EndRxTransfer(huart);//2.关闭串口接收
}
/*Call legacy weak error callback*/
HAL_UART_ErrorCallback(huart);//3.调用错误回调函数
}
}
所以解决办法是，只需要在HAL_UART_ErrorCallback错误回调函数中重新打开串口接收即可。
void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart)
{
if(huart == &hlpuart1)
{
__HAL_UNLOCK(huart);
HAL_UARTEx_ReceiveToIdle_DMA(&hlpuart1, (uint8_t*)receive_buff, 20);
}
}
经过以上分析，已经知道了串口死机的原因，和初步解决方案，在错误回调函数中重新打开串口。
但是在实际使用过程中，难免会有大量数据的收发，通过错误回调函数中重新打开串口只是治标不治本，ORE溢出错误的本意是告知用户目前通信超负荷需要进行调整，要么波特率太高，要么数据量太大数据处理不过来。
波特率一般是终端用户指定要求的，无法更改，那么只能更改在中断中的数据处理函数了。
解决方案：
要想知道怎么改中断中的数据处理函数，就需要明白在一个2MHz主频系统下，使用中断（或DMA）模式来接收串口数据，波特率为115200的情况下，中断处理程序允许的理论最大安全时间是多少？
115200的波特率在典型的“1起始位+1终止位+无校验位+8数据位”的配置下（每个数据帧对应10个bit），实际上对应最大11.52KB/s的数据率——或者说，USART完成中断每秒钟发生 11.52K次。即在这一系统中最大允许屏蔽中断多长时间——1/11.52KHz ≈87us。
由此可知：中断中的数据处理函数最长执行时间不能超过87us，否则将出现通信超载。
通过perf_counter工具实际测量data_parser代码的周期消耗： 修改代码如下：
经测量处理函数执行了2211个指令周期，由1MHz对应1us，1us对应一个指令周期可计算，2.097M的主频，1us可以执行2.097个指令周期，所以一共需要2211/2.097=1054us,超过了87us。
优化掉data_parser内部的耗时代码后，重新测量指令周期如下：
经测量处理函数执行了137个指令周期，一共需要137/2.097=66us,低于87us，经暴力测试，未出现溢出中断，符合预期。
注意：
STM32并不是所有的系列都有这个OverrunDisable开关，相应的也没有OVRDIS这个寄存器，清除ORE flag标志的方式也不相同。通过在STM32F103上测试，默认是开启了过载检测，由软件序列将其清零(先读USART_SR，然后读USART_CR)。
如果有OverrunDisable开关，在不使用HAL库的中断回调来实现串口接收时最好禁止Overrun，不然出现串口接收溢出，RDR寄存器中的值将不会改变，也就读不到新数据了。