问题：
$ {$ N1 |- l9 z, U( A  e$ T此问题由客户工程师提出，客户在使用 STM32F103 的 USART 做串口通讯时，发现了一个问题 ，当设备正常通信一段时间后，串口不响应外部的通信请求了.
- z4 I! e" O7 d5 B文中配图引用自 STM32F103 的中文版本用户手册 ,下载链接为 :
5 \. f4 h. u* U! F/ T
1 v3 ^) Y1 B6 @0 b# f& o
5 `0 O! I4 h& V% V7 k调研:
一、 经过调研:
1.1 客户除了使用 USART 做串口通信，还开启了定时器中断来进行数据采集.
) n! D- b2 r$ X$ \& m  P& C/ a1.2 定时器的优先级比串口接收的优先级高.
6 r: h# Z# C0 o6 C( _- V1.3 定时器处理数据操作也比较频繁.
, e6 J9 Q7 N  C' r; p/ j# T1.4 客户使用的 STM32F1 标准库(版本 V3.5.0).
二、经过问题复现和使用 ST-LINK 在线调试和定位发现:
* i5 H  X! e1 x, ^) D2.1 在出现这个问题的时候，程序不断的进入串口接收中断,不能够运行到 main 主函数处其他任务了.
  K6 W% }/ H; u" C0 j# p2.2 发现 ORE 标志为‘1’，也就说明程序是发生了串口溢出错误.
2.3 客户在进入串口中断后会调用 USART_GetITStatus(USART2, USART_IT_RXNE)来获取 RXNE 的值.如果 RXNE 为 1 则去读取 DR 数据寄存器的数据,读取后 RXNE 为 0，但是 ORE 的标志依然为 1,依然进入了串口中断.
三、 经过分析以及我们可以通过我们芯片的用户手册可以得到以下信息:
$ B0 z" ~1 J8 [3.1 程序不断进入串口中断是因为 ORE 标志始终为 1,没有被用户清除掉:
' g4 q! l# \( y3 S% V( m


8 m. @) P6 Y8 y从上图红色部分我们可以看到，如果串口接收中断开启了，那么 ORE 为 1 时就会产生中断.
3.2.从下图我们可以看到，顺序执行对 USART_SR 和 USART_DR 的操作就会清除 ORE 的标志,客户在中断中执行了以下操作，那为什么 ORE 标志还没有被清除呢?(R1 执行了读USART_SR 操作，R2 执行了读 USART_DR 操作).
, r, k0 g- a8 b7 s# m2 [! _
5 ]. j0 T  C# Y+ c/ O: L

3.3 我们可以看手册中下表的解释:
3.3.1 ORE 表征的是一个历史事件，当 ORE 为 1 时，表明至少有 1 个数据已经丢失.
3.3.2 这有 2 种可能发生的情况,RXNE 为 1 的情况 R3 和 RXNE 为 0 的情况 R4,如下图中的解释.
& ?3 a7 B, N2 |

- j, x0 X: P. u) h% w% M- _
3.3.3 我们从上图可以看出，3.2 图中的 R1+R2 操作只能处理 RXNE 为 1 的情况；
当 RXNE 为 0 的特殊情况, 就是在读序列器件(在 USART_SR 寄存器读访问和 USART_DR 读访问之间)接收到新的数据，数据 SR 虽然被读过了,但是 overrun 事件依然发生了，以上操作是不能够处理的：
6 }: |' T: }, x! J& ]" W% K


3.4 因此我们要在应用中对 ORE 标志进行处理，即当判断发生 ORE 中断的时候，我们再读一次USART_DR 的值，这样如果没有新的 Overrun 溢出事件发生的时候，ORE 会被清除,然后程序就不会因为 ORE未被清除一直不断的进入串口中断了,代码处理如下:
! f+ ], `  T5 I  u


" Z! \3 ]4 j, d& L结论：
8 k/ J; h8 a" E3 O7 y9 {4 w对于这种情况，我们可以看到 USART 串口接收中断使能了，那 ORE 中断也就开启了；为了消除在通过读序列(USART_SR/USART_DR)的过程中产生的溢出错误，我们可以尝试在应用程序中需要针对 ORE 标志做一个处理来清除 ORE 标志，使得串口通信可以正常的继续工作.
7 {! }; l. x/ O/ W' P# k8 y建议客户在做串口通信时需要增加帧检验功能，如 CRC 校验等...,当发生 ORE 时，帧校验肯定是通不过的，不会造成从机误响应.

) M: k3 u* h7 {, Z6 ?+ f" F8 p