前言

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

問題分析

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

圖 一

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

構建測試環境

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

代碼分析

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

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

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

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

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

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

小結

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