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