USART 中斷方式接收無響應問題的一種情況 及其處理方法

小融一號

問題：

此問題由客戶工程師提出，客戶在使用STM32F103的USART做串口通訊時，發現了一個問題，當設備正常通信一段時間后，串口不響應外部的通信請求了.

文中配圖引用自STM32F103的中文版本用戶手冊,下載鏈接為:

調研:

一、經過調研:

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時，幀校驗肯定是通不過的，不會造成從機誤響應.

重要通知 - 請仔細閱讀

意法半導體公司及其子公司（“ST”）保留隨時對ST 產品和/ 或本文檔進行變更、更正、增強、修改和改進的權利，恕不另行通知。買方訂貨之前應獲取關于ST 產品的最新信息。ST 產品的銷售依照訂單確認時的相關ST 銷售條款。

買方自行負責對ST 產品的選擇和使用， ST 概不承擔與應用協助或買方產品設計相關的任何責任。

ST 不對任何知識產權進行任何明示或默示的授權或許可。

轉售的ST 產品如有不同于此處提供的信息的規定，將導致ST 針對該產品授予的任何保證失效。

ST 和ST 徽標是ST 的商標。所有其他產品或服務名稱均為其各自所有者的財產。

本文檔中的信息取代本文檔所有早期版本中提供的信息。

文章來源：微信公眾號 融創芯城（一站式電子元器件、PCB、PCBA購買服務平臺，項目外包平臺）