前言

在一洗衣機MC項目中，客戶選擇使用STM32F030作為主控芯片。使用TIMER3(CH3)來捕獲電機的HALL Sensor的中斷，同時使用TIMER3（CH2）的OC功能，在OC match中斷中調(diào)整轉(zhuǎn)速。客戶在調(diào)試中發(fā)現(xiàn)，當捕獲中斷和OC中斷“同時發(fā)生（對齊）”時，會發(fā)生捕獲中斷丟失。

問題分析

客戶最初發(fā)現(xiàn)使用該配置控制電機時，在某一時刻會出現(xiàn)電機轉(zhuǎn)速異常。經(jīng)過抓取波形發(fā)現(xiàn)，HALL Sensor和捕獲輸出波形（在中斷中翻轉(zhuǎn)IO）不匹配，在某個時刻，會出現(xiàn)“中斷丟失”現(xiàn)象，表現(xiàn)為捕獲輸出高電平或低電平周期被拉長，如圖1所示。黃色為HALL信號，綠色為捕獲中斷輸出，紫色為OC中斷輸出，可以明顯看到在第四個上升沿之后，高電平長度被拉長半個周期。客戶懷疑是硬件Bug導致中斷“同時發(fā)生”時，捕獲“中斷丟失”，從而導致該問題。

圖 一

查看Erratasheet， 沒有相關的描述。另外，硬件BUG導致中斷丟失的可能性較小，因為中斷同時發(fā)生的概率很低而該現(xiàn)象很容易復現(xiàn)。

構(gòu)建測試環(huán)境

通過CubeMx構(gòu)建對應的測試工程，分別在捕獲和OC中斷中翻轉(zhuǎn)IO來檢測中斷狀況。另外，通過其它開發(fā)板產(chǎn)生相應的PWM來模擬HALL信號。經(jīng)過測試發(fā)現(xiàn)，使用Cube庫生成的代碼，并沒有“丟失中斷”的現(xiàn)象，波形見下圖。

代碼分析

客戶的代碼，包括中斷服務函數(shù)都是通過直接操作寄存器的方式編寫。分析客戶的代碼發(fā)現(xiàn)，客戶在中斷服務函數(shù)中清除相關中斷標志位時是通過常用的寄存器操作方式“讀-修改-寫”來完成，如下：

TIM3->SR&= ~TIM_SR_CC3IF; /* Clear the flags */

而在HAL Driver中是通過對應的位直接賦值的方式清除，如下：

#define__HAL_TIM_CLEAR_IT(__HANDLE__, __INTERRUPT__) ((__HANDLE__)->Instance->SR= ~(__INTERRUPT__))

結(jié)合客戶觀察到的現(xiàn)象，懷疑可能的原因是捕獲中斷標志在從讀狀態(tài)寄存器到寫入寄存器之間被置位，這樣的話，該標志就可能未被檢測處理到就被清除掉了，從而導致異常的發(fā)生。

將HAL Driver函數(shù)中的中斷服務函數(shù)修改成與客戶一樣的“讀-修改-寫”方式來清除對應標志位，該問題被復現(xiàn)。

小結(jié)

如果通過直接操作寄存器的方式來集成底層驅(qū)動，那么在通過“讀-修改-寫”方式操作此類會由硬件修改的寄存器時，一定要加倍小心。根據(jù)寄存器具體的描述，可以采用直接寫入或者聯(lián)合體（按位修改）的方式修改。