基于TIMER3發(fā)生捕獲中斷丟失問題分析與總結(jié)

前言

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

問題分析

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

圖 一

查看Erratasheet， 沒有相關(guān)的描述。另外，硬件BUG導(dǎo)致中斷丟失的可能性較小，因?yàn)橹袛嗤瑫r(shí)發(fā)生的概率很低而該現(xiàn)象很容易復(fù)現(xiàn)。

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

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

代碼分析

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

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

而在HAL Driver中是通過對(duì)應(yīng)的位直接賦值的方式清除，如下：

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

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

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

小結(jié)

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