GD32F350奇怪的uart溢出中断

最新推荐文章于 2024-08-06 11:27:51 发布

原创最新推荐文章于 2024-08-06 11:27:51 发布 · 2.1k 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#单片机

nrf51822 蓝牙单片机 ble 专栏收录该内容

6 篇文章

订阅专栏

博主在STM32项目中遇到一个奇怪问题，原本只设置了RBNE和IDLE中断，但在接收到数据后，系统不断进入中断处理程序，经排查发现是USART_INT_FLAG_RBNE_ORERR——溢出中断在作祟。尽管未启用该中断，它却莫名触发。通过细致的中断标志检查，最终解决问题，通过在中断处理中清除该标志恢复正常运行。

本来只是设置了RBNE和IDLE中断来接收数据的，奇怪的是接到数据后不停进入中断处理程序，但每次又不是RBNE和IDLE中断，陷入无穷劫，整个工程不能好好走了。。。发个狠，看看到底是谁中断了，于是在中断处理中加了n个

if（ RESET != usart_interrupt_flag_get(USART0, USART_INT_FLAG_XXX)）{}

分支一个个来，终于发现是 USART_INT_FLAG_RBNE_ORERR这个玩意起来了。一看，是溢出中断，可是有两个奇怪的地方：（1）USART_INT_FLAG_ERR_ORERR: overrun error interrupt flag 也是溢出中断，两个说明似乎没啥区别，为啥是RB_ORERR？（2）我没有使能这个中断啊，它咋就自己起来了？也许我少见多怪，只是这十几年来，却对这个现象没印象。

很是讨厌gd的例程了，越来越对付，翻了好几个demo suite，竟然没一个uart用idle中断的例程。。。不过既然出现了，懒得深究，直接在中断处理中加一个分支好了，读其状态，然后clear，搞定：

   else if(usart_interrupt_flag_get(USART0, USART_INT_FLAG_RBNE_ORERR)!=RESET)
   {
       usart_interrupt_flag_clear(USART0, USART_INT_FLAG_RBNE_ORERR);
   }

然后，工程正常跑起来了。