調研:一、經過調研:1.1 客戶除了使用USART做串口通信，還開啟了定時器中斷來進行數據采集.1.2 定時器的優先級比串口接收的優先級高.1.3 定時器處理數據操作也比較頻繁.1.4 客戶使用的STM32F1標準庫(版本V3.5.0).二、經過問題復現和使用ST-LINK在線調試和定位發現:2.1 在出現這個問題的時候，程序不斷的進入串口接收中斷,不能夠運行到main主函數處理其他任務了.2.2 發現ORE標志為‘1’，也就說明程序是發生了串口溢出錯誤.2.3 客戶在進入串口中斷后會調用USART_GetITStatus(USART2, USART_IT_RXNE)來獲取RXNE的值.如果RXNE為1則去讀取DR數據寄存器的數據,讀取后RXNE為0，但是ORE的標志依然為1,依然進入了串口中斷.三、經過分析以及我們可以通過我們芯片的用戶手冊可以得到以下信息:3.1 程序不斷進入串口中斷是因為ORE標志始終為1,沒有被用戶清除掉:從上圖紅色部分我們可以看到，如果串口接收中斷開啟了，那么ORE為1時就會產生中斷.3.2.從下圖我們可以看到，順序執行對USART_SR和USART_DR的操作就會清除ORE的標志,客戶在中斷中執行了以下操作，那為什么ORE標志還沒有被清除呢?(R1執行了讀USART_SR操作，R2執行了讀USART_DR操作).3.3 我們可以看手冊中下表的解釋:3.3.1 ORE表征的是一個歷史事件，當ORE為1時，表明至少有1個數據已經丟失.3.3.2這有2種可能發生的情況,RXNE為1的情況R3和RXNE為0的情況R4,如下圖中的解釋.3.3.3我們從上圖可以看出，3.2圖中的R1+R2操作只能處理RXNE為1的情況；當RXNE為0的特殊情況, 就是在讀序列器件(在USART_SR寄存器讀訪問和USART_DR讀訪問之間)接收到新的數據，數據SR雖然被讀過了,但是overrun事件依然發生了，以上操作是不能夠處理的：3.4 因此我們要在應用中對ORE標志進行處理，即當判斷發生ORE中斷的時候，我們再讀一次USART_DR的值，這樣如果沒有新的Overrun溢出事件發生的時候，ORE會被清除,然后程序就不會因為ORE未被清除一直不斷的進入串口中斷了,代碼處理如下:結論：對于這種情況，我們可以看到USART串口接收中斷使能了，那ORE中斷也就開啟了；為了消除在通過讀序列(USART_SR/USART_DR)的過程中產生的溢出錯誤，我們可以嘗試在應用程序中需要針對ORE標志做一個處理來清除ORE標志，使得串口通信可以正常的繼續工作.建議客戶在做串口通信時需要增加幀檢驗功能，如CRC校驗等...,當發生ORE時，幀校驗肯定是通不過的，不會造成從機誤響應.(mbbeetchina)