這里主要涉及到3個寄存器。WDG預(yù)分頻器，WDG控制寄存器[WWDG_CR]，看門狗配置寄存器[WWDG_CFR]。WWDG_CR決定計數(shù)器的上限并控制WWDG的啟停。WWDG_CFR里的W[6:0]決定喂狗的起始時刻，從該點到0x40形成一個有效喂狗時間窗口，即只有當(dāng)WDG計數(shù)器的值位于這個范圍時才可以做喂狗重載操作。否則，如果在計時器的值大于W[6:0]時喂狗或者計數(shù)器的值從0x40變?yōu)?x3F時都會觸發(fā)芯片復(fù)位。
“剛接觸使用WWDG,嘗試通過定時器定時喂狗。使用TIMER2并開啟溢出中斷，在中斷里置位喂狗提醒標(biāo)志。在主函數(shù)里監(jiān)測提醒標(biāo)志，若監(jiān)測到喂狗標(biāo)志置位，則進(jìn)行喂狗操作并清零喂狗標(biāo)志。可是發(fā)現(xiàn)每當(dāng)打開WWDG后，感覺就進(jìn)不去定時中斷了，總是喂狗失敗導(dǎo)致不停復(fù)位。如果關(guān)閉WWDG，定時中斷正常；不用TIMER中斷，用while延遲相等時間，也可喂狗成功。想不通為什么WWDG會導(dǎo)致中斷失敗？”
在討論這個問題之前不妨簡單看看STM32芯片里的窗口看門狗[WWDG]的一些基本特性和主要控制寄存器。至于STM32看門狗的細(xì)節(jié)知識建議閱讀各系列的參考手冊為宜。
窗口看門狗通常側(cè)重于用來監(jiān)測因外部干擾或不可預(yù)見的邏輯條件造成的應(yīng)用程序背離正常的運(yùn)行序列而產(chǎn)生的軟件故障。實質(zhì)上它是個可編程的自由運(yùn)行7位遞減計數(shù)器。
這里主要涉及到3個寄存器。WDG預(yù)分頻器，WDG控制寄存器[WWDG_CR]，看門狗配置寄存器[WWDG_CFR]。WWDG_CR決定計數(shù)器的上限并控制WWDG的啟停。WWDG_CFR里的W[6:0]決定喂狗的起始時刻，從該點到0x40形成一個有效喂狗時間窗口，即只有當(dāng)WDG計數(shù)器的值位于這個范圍時才可以做喂狗重載操作。否則，如果在計時器的值大于W[6:0]時喂狗或者計數(shù)器的值從0x40變?yōu)?x3F時都會觸發(fā)芯片復(fù)位。
好，繼續(xù)上面的話題。
現(xiàn)在發(fā)帖者覺得因為開啟了WWDG從而TIM2不進(jìn)中斷，覺得費解。結(jié)合上面WWDG的原理，這個比較容易想到WWDG從初始的T[6:0]一直遞減計數(shù)到0X3F沒有被喂狗而發(fā)生了復(fù)位。很可能TIM2的定時周期長于或者遠(yuǎn)長于WWDG從T[6:0]計數(shù)到0X3F的時間，這樣每次TIM2來不及進(jìn)中斷設(shè)置相關(guān)標(biāo)志就被WWDG復(fù)位了,這樣循環(huán)往復(fù)。當(dāng)然，這只是基于問題癥狀一種可能。
發(fā)帖者就時間參數(shù)作了進(jìn)一步確認(rèn)，認(rèn)為定時中斷的時間點完全落在喂狗窗口范圍內(nèi)，而且關(guān)閉WWDG后，TIM2 周期性更新中斷也正常。不使用TIM2，改為別的延時定時方式又能成功喂狗。
看來問題不是出在那個TIM2定時參數(shù)與窗口時間安排上。后來發(fā)帖者調(diào)試中無意發(fā)現(xiàn)每次開啟定時器TIM2 都會進(jìn)一次中斷。這一進(jìn)中斷就問題來了，中斷里置位了喂狗喚醒標(biāo)志，退出后主程序見到喚醒標(biāo)志立即做喂狗操作。顯然這下喂早了，WWDG發(fā)揮功能了，復(fù)位芯片！復(fù)位后每次開啟定時器時故伎重演，又是提前喂狗，導(dǎo)致復(fù)位，周而復(fù)始。這樣給人以TIM2沒進(jìn)中斷，WWDG沒有得到及時喂狗而復(fù)位的假象。其實呢，喂狗喂的時間不合適而已。
原因找到了，就比較好解決了。發(fā)帖者調(diào)整了一下代碼，在使能TIMER前先清下相應(yīng)的UIF位就好。順便提下，盡量不要在中斷里進(jìn)行喂狗操作。
至于TIMER配置過程中一使能就產(chǎn)生更新中斷問題，有人可能遇到或留意到這點了。有些情況下它可能會對應(yīng)用帶來影響或麻煩。在使能前先做下相關(guān)標(biāo)志的清除也是個不錯的辦法。再就是注意下配置代碼順序也可以回避。
相關(guān)話題鏈接：
| 歡迎光臨 (http://www.zg4o1577.cn/bbs/) | Powered by Discuz! X3.1 |