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