一個關于STM32 WWDG應用的相關話題

    “剛接觸使用WWDG,嘗試通過定時器定時喂狗。使用TIMER2并開啟溢出中斷，在中斷里置位喂狗提醒標志。在主函數(shù)里監(jiān)測提醒標志，若監(jiān)測到喂狗標志置位，則進行喂狗操作并清零喂狗標志。可是發(fā)現(xiàn)每當打開WWDG后，感覺就進不去定時中斷了，總是喂狗失敗導致不停復位。如果關閉WWDG，定時中斷正常；不用TIMER中斷，用while延遲相等時間，也可喂狗成功。想不通為什么WWDG會導致中斷失��？”

    在討論這個問題之前不妨簡單看看STM32芯片里的窗口看門狗[WWDG]的一些基本特性和主要控制寄存器。至于STM32看門狗的細節(jié)知識建議閱讀各系列的參考手冊為宜。

    窗口看門狗通常側重于用來監(jiān)測因外部干擾或不可預見的邏輯條件造成的應用程序背離正常的運行序列而產(chǎn)生的軟件故障。實質上它是個可編程的自由運行7位遞減計數(shù)器。

        這里主要涉及到3個寄存器。WDG預分頻器，WDG控制寄存器[WWDG_CR]，看門狗配置寄存器[WWDG_CFR]。WWDG_CR決定計數(shù)器的上限并控制WWDG的啟停。WWDG_CFR里的W[6:0]決定喂狗的起始時刻，從該點到0x40形成一個有效喂狗時間窗口，即只有當WDG計數(shù)器的值位于這個范圍時才可以做喂狗重載操作。否則，如果在計時器的值大于W[6:0]時喂狗或者計數(shù)器的值從0x40變?yōu)?x3F時都會觸發(fā)芯片復位。

     好，繼續(xù)上面的話題。

    現(xiàn)在發(fā)帖者覺得因為開啟了WWDG從而TIM2不進中斷，覺得費解。結合上面WWDG的原理，這個比較容易想到WWDG從初始的T[6:0]一直遞減計數(shù)到0X3F沒有被喂狗而發(fā)生了復位。很可能TIM2的定時周期長于或者遠長于WWDG從T[6:0]計數(shù)到0X3F的時間，這樣每次TIM2來不及進中斷設置相關標志就被WWDG復位了,這樣循環(huán)往復。當然，這只是基于問題癥狀一種可能。

    發(fā)帖者就時間參數(shù)作了進一步確認，認為定時中斷的時間點完全落在喂狗窗口范圍內，而且關閉WWDG后，TIM2 周期性更新中斷也正常。不使用TIM2，改為別的延時定時方式又能成功喂狗。

    看來問題不是出在那個TIM2定時參數(shù)與窗口時間安排上。后來發(fā)帖者調試中無意發(fā)現(xiàn)每次開啟定時器TIM2 都會進一次中斷。這一進中斷就問題來了，中斷里置位了喂狗喚醒標志，退出后主程序見到喚醒標志立即做喂狗操作。顯然這下喂早了，WWDG發(fā)揮功能了，復位芯片！復位后每次開啟定時器時故伎重演，又是提前喂狗，導致復位，周而復始。這樣給人以TIM2沒進中斷，WWDG沒有得到及時喂狗而復位的假象。其實呢，喂狗喂的時間不合適而已。

    原因找到了，就比較好解決了。發(fā)帖者調整了一下代碼，在使能TIMER前先清下相應的UIF位就好。順便提下，盡量不要在中斷里進行喂狗操作。

   至于TIMER配置過程中一使能就產(chǎn)生更新中斷問題，有人可能遇到或留意到這點了。有些情況下它可能會對應用帶來影響或麻煩。在使能前先做下相關標志的清除也是個不錯的辦法。再就是注意下配置代碼順序也可以回避。

相關話題鏈接：

STM32定時器有時一開啟就進中斷的話題