??在使用STM32F207這一款單片機除錯串口的時候，使用兩種不同的中斷接收方式:幀中斷IDLE和位元組中斷RXNE，會出現一些神奇的事情，只要我們認真地分析是可以揭開BUG后面隱藏的真相，其中IDLE中斷也叫作串口空閑中斷，

一、問題背景

1.1 硬體連接框圖

??如圖1所示是簡化的硬體連接框圖，本來有18個SLAVE設備，問題的復現只需要兩個所以只畫了兩個SLAVE設備，MASTER和SLAVE1、SLAVE2使用485總線進行通信，其中MONITOR是一個監聽設備，用于監聽所有在總線上的資料，監聽資料并分析是在除錯各類總線型通信時常用的手段，兩個120歐電阻是首尾匹配電阻所以485總線的阻抗是60歐，

??其中SLAVE1、SLAVE2、MONITOR都是使用STM32F207+ADM2682擴展出來485，接收方式是使用幀中斷；MASTER是對方設計的所以不清楚使用的主控芯片、中斷方式是幀中斷接識訓是位元組中斷接收，通過圖6可以分析出來應該是位元組中斷，因為MASTER反應時間t2是遠小于SLAVE的反應時間t1，

??雙方約定命令主要有兩種：①、MASTER會定時20ms向SLAVE發送取數指令，SLAVE向MASTER回傳傳感器測驗值Y；②、如果MASTER決議出來傳感器測驗值Y在[-X，X]范圍內，MASTER會向SLAVE發送清零指令，SLAVE需要將Y值清零，SLAVE不需要回傳任何資料，

1.2 玄學的BUG

??前期自測：因為沒有MASTER設備，所以使用USB-485模塊模擬MASTER設備，使用XCOM串口軟體作為上位機發送取資料指令以及清零指令，單獨測驗讀資料命令時，定時20ms，SLAVE每次都回回傳資料無丟幀，

??因為MSATER和SLAVE之間的資料互動都是一包資料10個位元組的，所以使用了串口的USART_IT_IDLE中斷就是幀中斷，它是當串口收到一幀資料或者說一包資料后產生的中斷，以MASTER發送給SLAVE2的取資料指令包含10個位元組:AA 01 52 00 00 00 00 00 52 85，當接收完0xAA時，會觸發一次USART_IT_RXNE位元組中斷，而不會觸發USART_IT_IDLE幀中斷，當接收完0x85后，會觸發USART_IT_RXNE位元組中斷和USART_IT_IDLE幀中斷，所以這個命令會觸發10次USART_IT_RXNE位元組中斷和1次USART_IT_IDLE幀中斷，

??中期聯調：當SLAVE傳感器值Y不在[-X，X]范圍時（藍色部分），無例外現象；當SLAVE傳感器值Y在[-X，X]范圍時（藍色部分），預期現象時會出現清零，即Y值會顯示為0，但是實測出現了如圖3所示的不清零情況，-0.7因為在[-X，X]范圍內，所以-0.7會瞬間變成0，但是一直在0.7停留，并且狀態燈一直是綠色的，所以通信是沒有斷掉的【有一次沒有回傳資料就會綠燈變成紅色，并且通過MONITOR記錄下的資料發現是每次都會回傳資料的，所以MONITOR是很有必要的，用以BUG除錯時的資料記錄回看】，即MASTER的取資料命令都得到了SLAVE的反應，

??因為出現了玄學現象，為了復現BUG所以通過改變傳感器的狀態使傳感器值反復經過[-X，X]紅色線部分看看能不能復現故障，復現的一次情況是SLAVE1設備的角度在1.3度停止不動，并且不會清零，通過在線Debug查看MONITOR接收到的資料，發現一個幀中斷接受到了30個資料，前十個位元組資料是SLAVE1回的資料（其中決議出來的資料是1.3，屬于紅色線范圍，會被MASTER清零），中間十個位元組是SLAVE向SLAVE1發出的清零指令，后面十個位元組是MASTER向SLAVE2發出的讀角度指令，

??這里有個問題為什么不Debug SLAVE1設備呢？其實是Debug了的，只不過沒有有效的識訓，因為導致這個BUG的原因是SLAVE1+MASTER+SLAVE2一起導致的，如果Debug這三個中的任何一個單個設備，均不能復現這個BUG，

• BB 00 52 01 66 66 A6 3F 68 EF 是SLAVE1回MASTER設備的資料指令，10個位元組

• AA 09 53 00 00 00 00 00 22 05 是MASTER發送給SLAVE1的清零指令，10個位元組

• AA 01 52 00 00 00 00 00 52 85 是MASTER發送給SLAVE2的取資料指令，10個位元組

??使用Debug發現了一次幀中斷出現了“三包資料”（這里的“三包資料”指的是本應該是三包資料的，但是卻被識別成了一包資料，所以這里帶引號的三包資料實際上按照一包資料接收的，同理“兩包資料”），本來是一包資料就會觸發一次幀中斷的，也就是說本應該觸發三次幀中斷的只觸發了一次幀中斷如圖4所示，也有出現一次幀中斷接收“兩包資料”的，當時只保存了示波器抓到一次幀中斷接收“兩包資料”的波形，沒有Debug時的RS485_RX_BUF截圖，

1.3 幀中斷觸發條件

??中斷產生條件：STM32的幀中斷是IDLE中斷，當接收到一幀資料，就會產生IDLE中斷，幀中斷常被用于接收不定長度位元組資料，
??優點：因為IDLE中斷是一幀資料/一包資料產生一次中斷，然后讀取暫存器里面存取的資料可以獲得本次幀中斷所接收的資料長度與資料內容，即使某一幀由于未知原因增加一個位元組或者減小一個位元組，可以根據接收到的資料長度和約定的不一致所以不采用這一幀資料，但是下一幀資料是不受前面錯誤幀資料的影響，這個是下面使用位元組中斷可能會出現的問題，
??缺點：當使用幀中斷時，因為判斷幀結束的標志需要默認電平持續的時間>發送一個位元組所需要的時間，所以對于一幀資料的回應時間一定是大于一個位元組資料信號的時間，即下文的 t Byre t_{\text {Byre}} tByre?，

1.4 位元組中斷觸發條件

??中斷產生條件：STM32的位元組中斷是RXNE中斷，當接收到1個位元組，就會產生RXNE中斷，位元組中斷可以用來接收定長位元組資料，比如針對上面的AA 09 53 00 00 00 00 00 22 05命令，每接收到一個位元組資料，觸發一次RXNE中斷，RxCount++、保存接收到的這一位元組資料到RXBuffer并指標加1，當接收到的資料計數到10（10時約定好的命令）時，判斷RXBuffer是否是約定的命令，如果是則進行Response，
??缺點：使用RXNE中斷的缺點顯而易見，因為沒有按照一幀資料一幀資料接收，一旦某一幀因為未知原因增加一個位元組或者減小一個位元組就會導致后續接收到的資料包是錯位的，所以相應地需要增加相應措施解決這個問題，
??優點：這個優點是相對于幀中斷來講的，因為按照位元組來接收到的，而單片機對于一個位元組資料產生中斷所需要的時間與 t Byte t_{\text {Byte}} tByte?暫時沒有發現有關系（不知道與發送一位資料所需要的時間是否有關， t bit t_{\text {bit}} tbit?），所以其回應時間相比著幀中斷會快很多，本文為了將“兩包資料”中包含的命令決議出來，最后就是將幀中斷改為了位元組中斷去接收，然后回圈判斷是否是約定的命令，
后面需要查找資料：485總線上資料格式，如何判定一位，一位資料與中間電平是否有關系

二、解決問題

2.1 復現BUG：一個幀中斷“2包資料”？

??發現了是幀中斷導致的一個幀中斷接收了多幀資料，我們從事故的一開始分析一個幀中斷是如何導致接收到“兩包資料”的，首先是MASTER發送給SLAVE1的讀資料命令為事件的起始點，從MASTRE、SLAVE1、SLAVE2、MONITOR四個角度看485總線上都發生了，因為MONITOR是不參與命令互動的，所以以MONITOR為視角看到的485總線上的信號時序圖是出現在485總線上的所有信號的真實時序，如圖5所示，其中

• t1大小的影響因素：SLAVE1對M→S1讀資料命令的反應時間
• t2大小的影響因素：MASTER對S1→M回資料命令的反應時間，判定在閾值范圍的紅色曲線上，所以需要清零，如果是藍色區域，則沒有這一步，
• t3大小的影響因素：因為t3位于M→S1清零和與M→S2讀資料這兩個命令之間，這兩個命令都是由MASTER發送的，中間應該是沒有時間差的，
• t4大小的影響因素：SLAVE2對M→S2讀資料命令的反應時間
• 過渡電平是485總線上沒有資料時總線的默認電平，等于(Vh+Vl)/2，485的空閑是差分的所以應該是中間值同CAN與CANFD，TTL的空閑電平是邏輯高電平，
• 圖6中t1前面的信號為一幀資料，記為第1幀；t1后面的信號為一幀資料，記為第2幀，對于圖5，t1后面t3前面，“2+t2+3”是第2幀；t1前面即“1”是第1幀，

??使用示波器捕捉的“兩包資料”合為一幀的波形如圖6所示，此時示波器的時間刻度是2.5ms（沒拍好所以看不清楚了），串口的波特率是9600，單片機經過芯片ADM2682將TTL電平轉化為485電平，因為只是電平的轉換，所以轉換后的485信號的波特率依舊是9600，所以發送一位需要的時間是1s/9600，對于串口除了設定波特率外，我們還要設定停止位（1）、資料位（8）、奇偶校驗位（無），所以發送一個位元組需要 t Byte = ( 1 s / 9600 ) ? 9 = 0.9375 m s t_{\text {Byte}}=(1 s / 9600) \cdot 9=0.9375 \mathrm{ms} tByte?=(1s/9600)?9=0.9375ms，所以要區分開來兩幀資料如第1幀和第2幀，那么兩幀資料之間過渡電平的持續時間t1應該大于 t Byte t_{\text {Byte}} tByte?，這樣才能識別為兩幀資料；按照這個來發送一位資料需要時間 t bit = ( 1 s / 9600 ) = 0.1042 m s t_{\text {bit}}=(1 s / 9600)=0.1042 \mathrm{ms} tbit?=(1s/9600)=0.1042ms，怎么區分是兩個位元組資料(查資料后補充)，
??使用下面的代碼測驗串口在一包資料出現多久可以以觸發IDLE中斷，測驗的結果如圖7所示，代碼示例如下，可以發現一包資料需要等待1ms的時間才會觸發IDLE中斷，后面可以通過改變波特率驗證，波特率越高，等待時間越小，
??在MODBUS通信協議幀資料之間的停頓間隔**“3.5字符”定義：MODBUS通訊規定主機發送完一組命令必須間隔3.5個字符再發送下一組新命令，這個3.5字符主要用來告訴其他設備這次命令已經結束，3.5個字符的定義在波特率為9600的情況下，只要大于4.01ms即可，計算方法同上，只不過發送一個位元組按照最大時間來計算所以發送一個位元組需要 t Byte = ( 1 s / 9600 ) ? 11 = 1.1458333 m s t_{\text {Byte}}=(1 s / 9600) \cdot 11=1.1458333 \mathrm{ms} tByte?=(1s/9600)?11=1.1458333ms，即停止位2、資料位8、有奇/偶檢驗一共11位**，

void USART1_IRQHandler(void)
{
	if(USART_GetFlagStatus(USART1,USART_FLAG_IDLE)!=Bit_RESET)//如果接收到1幀資料
	{
       	PA10_High();//拉高GPIO PA10
        clear=USART1->SR;//讀SR暫存器
        clear=USART1->DR;//讀DR暫存器(先讀SR暫存器再讀DR，就是為了清除IDLE中斷)						
		PA10_Low();//拉低GPIO PA10
    }	
} 

??根據兩包資料合為一包資料的原因，推測三包資料合為一包資料的485總線上的時序圖如圖8所示，因為沒有捕捉到波形，所以這里只是猜測，沒有得到驗證，后續想辦法模擬驗證吧，推測是t2和t3太短，導致S1→M回資料與M→S1清零與M→S2讀資料這三幀資料合并為了一幀資料，因為SLAVE設備是使用幀中斷進行接收的，所以t1=t4> t Byre t{\text {Byre}} tByre即反應比較慢，他們回資料信號不會和前面的讀資料信號混到一起成為一幀資料，即1和2是不會混為一幀資料，4和5不會混為一幀資料，只有使用位元組中斷的會導致反應比較快如t2< t Byre t{\text {Byre}} tByre，即2+3+4合為了一幀資料，

2.2 專案總結思考

??因為不知道對方MASTER設備的接收中斷方式使用的是幀中斷還是位元組中斷，所以提前確認好對方設備或者說專案中的測驗設備及對接設備的通信具體形式等細節是十分有必要的，否則單獨測驗時雙方都是OK的，等到聯調的時候就會出現一些玄學的BUG，
??我們要做到首先遇到BUG不要慌，BUG不會憑空產生，而是許多關鍵事件的連鎖反應，其次判斷BUG是人為失誤還是設計有瑕疵，就需要我們去剖析那些BUG的細節，尋找線索，