STM32L0 LPUART串口ORE溢出错误处理

项目场景:

使用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,否则将出现通信超载。
首先屏蔽掉回调函数中的用户代码,只测量HAL库LPUART1_IRQHandler本身所消耗的时间:

在这里插入图片描述
通过perf_counter工具实际测量LPUART1_IRQHandler消耗的时钟周期:
在这里插入图片描述
经测量处理函数执行了628个指令周期,由1MHz对应1us,1us对应一个指令周期可计算,2.097M的主频,1us可以执行2.097个指令周期,所以一共需要628/2.097=299us。
由此可知,如果使用HAL库,2.097M的主频,满足不了115200的波特率,特别是在使用中断接收时,会出现接收不到完整数据的现象。
因此如果又想使用115200,又不能增加主频的情况下,要么不使用HAL库,要么就只能使用的是DMA+空闲中断接收的方式,才能接收到一帧完整的数据。

假设使用DMA+空闲中断的方式接收数据,中断进入LPUART1_IRQHandler后,会消耗掉299us,再调用回调函数,处理用户代码,用户代码还是要尽量的短,另外加长DMA接收的数据长度,也可以尽可能的避免发生溢出错误。

修改data_parser代码后,测量指令周期如下:
在这里插入图片描述
在这里插入图片描述

经测量处理函数执行了137个指令周期,需要137/2.097=66us,整个处理时间为299us+66us=365us。

通过代码优化,降低了发生串口溢出的风险,增加错误回调HAL_UART_ErrorCallback代码,当发生串口溢出时,及时重新开启,经实际测试,可以满足项目需求。

注意:

STM32并不是所有的系列都有这个OverrunDisable开关,相应的也没有OVRDIS这个寄存器,清除ORE flag标志的方式也不相同。通过在STM32F103上测试,默认是开启了过载检测,由软件序列将其清零(先读USART_SR,然后读USART_CR)。

如果有OverrunDisable开关,在不使用HAL库的中断回调来实现串口接收时最好禁止Overrun,不然出现串口接收溢出,移位寄存器中的数据会被覆盖,RDR寄存器中的值将不会改变,也就读不到新数据了。

  • 9
    点赞
  • 68
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
### 回答1: STM32 USART ORE指的是STM32微控制器中USART模块中出现的“Overrun Error(ORE)”,也叫“溢出错误”。USART模块是一种通信接口,用于在微控制器与外部设备之间进行串行通讯。如果在接收数据时,接收缓冲区已经满了,但是继续接收数据,就会导致信息的溢出,即“Overrun Error”。 在STM32的USART模块中,当接收缓冲区满时,接收到的新数据会被丢弃,同时会触发ORE错误。如果发生ORE错误,需要及时处理错误,否则可能会导致通讯异常或数据丢失。 解决ORE错误的方法可以采取以下措施: 1. 增加接收缓冲区的大小,避免缓冲区溢出。 2. 在接收数据之前检查接收缓冲区的状态,避免数据溢出。 3. 设置接收数据的超时时间,当超过设定时间仍未接收到新数据时,自动清除接收缓冲区,避免数据溢出。 总之,STM32 USART ORE是USART模块中常见的错误,需要注意避免和及时处理。 ### 回答2: STM32是意法半导体公司生产的一种微控制器,具有出色的性能和可靠的稳定性,被广泛应用于各种嵌入式系统中。USART是STM32中一种强大的通信接口,可以实现高速的串行通信,实现实时数据传输功能。ORE是USART通信中的一种错误标志,表示发生了数据溢出,即接收缓冲区已满,而有新的数据进来无法存储。导致ORE错误的原因是接收速率过快,导致MCU无法及时处理接收到的数据,从而造成接收缓冲区溢出。在发生ORE错误时,需要对接收缓冲区进行清空操作,以避免数据丢失,同时调整接收速率,避免再次发生这种错误。除了ORE错误外,USART通信中还有其他的错误标志,如PE(奇偶校验错误)、FE(帧错误)、NE(噪声错误)等,需要在实际应用中进行仔细调试和处理,以保证通信的可靠性和稳定性。 ### 回答3: STM32 USART是由ST公司推出的一种串行通信接口,可以实现高效的串行数据传输。它适用于各种各样的应用场景,包括通信、控制、监测等。 USART接口支持多种通信协议,例如异步串行通信协议(UART)、同步串行通信协议(SPI、I2C等),并且还拥有很多优良的特性,例如快速的数据传输速度、多种数据格式的支持、多种工作模式的选择、多个收发数据缓冲器的支持等等。 在STM32 USART中,ORE(Overrun Error)指的是串口缓存器接收到了下一段数据,但接收缓存器还未处理完前一段数据的情况。这就会导致后续的数据覆盖缓存区,造成丢失数据的问题。 为了解决这个问题,可以采用一些措施: 1. 设计合适的通信协议,确保数据帧长度和数据帧停歇时间足够长,以避免ORE现象的发生。 2. 增加USART接收缓冲器的容量,减少ORE现象的造成。 3. 在接收ISR中处理ORE错误,及时清除接收缓冲器中的多余数据,以确保数据的准确性。 总之,STM32 USART是一个功能强大、灵活多变的串口通信接口,它可以通过一些方法避免ORE现象的发生,从而更好地完成数据的传输和处理。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

WALI-KANG

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值