【原】MCU看門狗到底能不能在低功耗下工作？

最近一群友在群里問了一個關于低功耗下看門狗工作的問題：

引起了各路大蝦交流探討：

MCU都有看門狗（Watchdog）功能，它是用來監測及解決由軟件故障導致的系統故障，防止系統因程序跑飛、死循環導致長時間無響應。那么看門狗能不能在低功耗下工作呢？

我在10年前就很困惑這個問題，因為當時所在公司的MCU在低功耗模式下看門狗是壓根不工作的，但是當時有客戶明確提到需要支持這個功能。在一次部門周例會上，當我們討論到這個問題時，還被一位老前輩“教育”了一番，因為在他看來就不應該提出這個不合理的問題。

他解釋MCU進入低功耗，CPU已經休眠，程序不再運行，因此不存在'程序跑飛'的概念。從這個角度來看，確實不需要看門狗在低功耗下工作。

10年前和我提起這個需求的客戶解釋是因為他們擔心MCU在低功耗下可能會喚不醒，所以需要看門狗工作。這個說法在我那位資深同事看來更是不合理，他的觀點是：MCU在低功耗下不可能喚不醒；如果喚不醒，那說明MCU本身存在重大缺陷，這樣的MCU根本沒法用。他還舉例說明，某品牌客戶的空調遙控器所使用的MCU年用量達千萬級，也從未遇到過MCU喚不醒的情況。這說法聽起來好像也有道理，這么一說似乎也沒有必要讓看門狗在低功耗下工作了。

可是為什么很多MCU還是有這個功能呢？比如群友提到的GD32A503

在進入低功耗模式后，看門狗的作用已經不是防止“程序跑飛”，它的目的變成了“確保系統能從低功耗模式中按時醒來”，防止“睡死”。

系統進入低功耗模式后，通常是依靠某種喚醒源來恢復運行的，例如：

• 外部IO中斷：按鍵按下、傳感器信號變化。

• 其他外設中斷：如串口收到數據。

• 內部定時器：RTC或低功耗定時器。

如果配置喚醒源的代碼有Bug，或者喚醒源本身因為硬件問題（如晶振停振、傳感器故障）未能有效產生信號，系統就可能永遠無法醒來，就像“睡死”過去一樣。對于電池供電的物聯網設備，這意味著設備“變磚”，用戶只能通過拔電池來恢復。

很多低功耗應用場景要求設備即使沒有外部事件，也需要定時通過RTC醒來（例如每10分鐘采集一次數據并上傳）。如果預定的RTC喚醒因為某種原因失敗了，看門狗超時復位可以提供一個恢復的機會。

所以說MCU具備這個功能，我認為還是有實際價值的！

MCU的看門狗正常都會用，另外一旦開啟通常情況下是無法關閉的。對于在低功耗下看門狗可以工作的MCU，如何正確同時使用看門狗和低功耗呢？

對此，可以按照MCU是否支持低功耗模式下自動暫停計數功能分為兩類：

1）看門狗不支持低功耗模式下自動暫停計數

對于此類MCU，如上述GD32A503，由于進入低功耗模式后，看門狗還是繼續在計數，所以當超時時間到了之后就會引起復位，這種情況很多情況下并不是我們期望的（比如進入低功耗是通過按鍵喚醒，但是喚醒的時間是不確定的）。但是我們又必須使用看門狗，我們只能通過額外的定時器周期性地喚醒MCU進行喂狗。當然，如果業務邏輯本身就需要周期性喚醒（例如定時采集數據），那么只需在喚醒后正常喂狗即可。

2）看門狗支持低功耗模式下自動暫停計數

這一類的MCU設計的更加合理，如STM32L476，如果不需要在低功耗模式下看門狗計數，你可以選擇在進入低功耗前暫停看門狗計數（并不是徹底關掉看門狗），喚醒后看門狗正常計數，看門狗只在RUN模式才工作，這樣就靈活很多，避免了不必要的復位。

對于在低功耗下看門狗就是無法工作MCU，其實只要MCU自身喚醒可靠且相關喚醒源正常，實際應用也是沒有什么問題的。

所以MCU看門狗到底能不能在低功耗下工作還是要看MCU本身是否支持這個功能。