看门狗复位防止程序死锁

最新推荐文章于 2025-11-16 15:52:24 发布

原创最新推荐文章于 2025-11-16 15:52:24 发布 · 560 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#看门狗 # IWDG # WWDG

AI助手已提取文章相关产品：

看门狗复位防止程序死锁

在嵌入式世界里，最让人头疼的不是功能做不出来，而是设备“莫名其妙”地卡住——屏幕不动了、通信断了、电机停转了……可代码明明写得没问题啊？🤔

其实，这种“假死”现象背后，往往是程序陷入了死循环、任务死锁，或是被某个没加超时的等待卡得动弹不得。更糟的是，主控芯片还在“正常运行”，只是逻辑已经跑偏，没人能救它回来。

这时候，就需要一个“硬核保镖”出手了： 看门狗定时器（Watchdog Timer, WDT） 。
它就像个尽职的哨兵，盯着你的程序有没有按时“报到”。一旦发现你“失联”，二话不说直接重启系统——简单粗暴，但超级有效！💥

它是怎么工作的？

你可以把看门狗想象成一个倒计时炸弹 💣，只不过它的引信是由你来定期拆除的。

你启动它后，它就开始从某个数值往下数；
每当你调用一次“喂狗”函数，它就重置这个倒计时；
如果你忘了喂，或者程序卡住了没法喂…… boom！时间一到，自动触发复位，MCU重新启动。

这招看似原始，实则极为可靠——因为它通常由一个独立于主系统的低速时钟驱动（比如32kHz LSI），哪怕主时钟崩了、CPU乱跑了，它照样能工作。✅

🧠 小知识：为什么叫“看门狗”？
因为它就像一条拴在院子里的狗🐶，只要主人时不时出来摸摸它，它就安分守己；但要是主人失踪太久，它就会狂吠报警，甚至咬断绳子冲出去找人——最后干脆把你家大门关了重开！

不是所有“狗”都一样：IWDG vs WWDG

别以为看门狗就是个简单的计时器，高端玩家早就玩出了花。以STM32为代表的MCU，通常配备两种看门狗：

✅ 独立看门狗（IWDG）—— 老派硬汉

使用内部低速RC振荡器，不怕主系统崩溃；
只要不喂狗，超时就复位；
配置简单，适合大多数场景；
缺点：太“宽容”。哪怕程序只是在空循环里瞎转，只要按时喂狗，它也认为一切正常。

⚠️ 窗口看门狗（WWDG）—— 细节控杀手

这才是真正的“智能监控官”。

它不仅规定最晚什么时候必须喂狗，还规定最早什么时候才能喂！也就是说，喂早了不行，喂晚了也不行，必须在指定“窗口期”内操作才有效。🎯

举个例子：

// 假设当前计数器值从0x7F递减到0x3F
hwwdg.Init.Window = 0x50;  // 只有当计数器 > 0x50 时喂狗才合法

这意味着你只能在 0x51 ~ 0x7F 这个区间喂狗。如果程序跑得太快，在刚进入循环就喂了，会被判定为“无效心跳”并可能触发异常。

💡 这有什么用？
防止程序“虚假活跃”！例如主循环因为出错跳过了关键任务，只做了一个空循环，却依然频繁喂狗。普通看门狗看不出问题，但窗口看门狗会立刻识破：“你节奏不对，肯定有问题！”🚨

而且，WWDG还能在复位前发出中断预警，让你有机会保存日志、记录状态，简直是故障排查的好帮手。

实战代码：让看门狗真正跑起来

来看看如何在STM32上配置这两种看门狗。

🔧 IWDG 初始化（HAL库版）

#include "stm32f4xx_hal.h"

void Watchdog_Init(void) {
    IWDG_HandleTypeDef hiwdg;

    hiwdg.Instance = IWDG;
    hiwdg.Init.Prescaler = IWDG_PRESCALER_256;   // 分频系数
    hiwdg.Init.Reload = 500;                     // 重载值
    hiwdg.Init.Window = IWDG_WINDOW_DISABLE;

    if (HAL_IWDG_Init(&hiwdg) != HAL_OK) {
        Error_Handler();
    }
}

// 主循环中记得刷新！
while (1) {
    Task_Run();           // 执行业务逻辑
    HAL_IWDG_Refresh(&hiwdg);  // 喂狗！不能少
    HAL_Delay(100);
}

📌 注意点：
- 超时时间 ≈ (Reload + 1) × Prescaler / LSI频率 ，LSI一般约32kHz；
- 上面这段配置大约提供500ms左右的窗口；
- 喂狗一定要放在 所有关键任务之后 ，否则等于白搭！

🕵️ WWDG 更精细的控制

WWDG_HandleTypeDef hwwdg;

void WWDG_Init(void) {
    hwwdg.Instance = WWDG;
    hwwdg.Init.Prescaler = WWDG_PRESCALER_8;
    hwwdg.Init.Window = 0x50;          // 窗口下限
    hwwdg.Init.Counter = 0x7F;         // 初始值
    hwwdg.Init.EWIMode = WWDG_EWI_ENABLE;

    HAL_WWDG_Init(&hwwdg);

    HAL_NVIC_SetPriority(WWDG_IRQn, 0, 0);
    HAL_NVIC_EnableIRQ(WWDG_IRQn);
}

// 中断处理：最后的求救信号
void WWDG_IRQHandler(void) {
    if (__HAL_WWDG_GET_FLAG(&hwwdg, WWDG_FLAG_EWKUP)) {
        __HAL_WWDG_CLEAR_FLAG(&hwwdg, WWDG_FLAG_EWKUP);
        Log_System_Status();  // 快！记下现场！
    }
}

// 定时任务中精准喂狗
void Timing_Callback(void) {
    static uint8_t cnt = 0;
    cnt++;
    if (cnt >= 50) {  // 每200ms执行一次（假设SysTick为4ms）
        HAL_WWDG_Refresh(&hwwdg);
        cnt = 0;
    }
}

⚠️ 重要提醒：
- WWDG依赖PCLK1时钟，主时钟必须稳定；
- 窗口不能太窄，否则轻微抖动就会误触发；
- 别在中断里喂狗！主循环卡死但中断仍响应的情况很常见，容易造成“假活”错觉。

看门狗放哪儿喂？位置决定成败！

很多人以为“只要喂了就行”，其实不然。喂狗的位置非常讲究。

❌ 错误示范：

while (1) {
    HAL_IWDG_Refresh();  // 一开始就喂？那后面卡死也没用了！
    Task_A();            // 可能无限等待SPI回应
    Task_B();            // 根本执行不到
}

✅ 正确做法：

while (1) {
    Task_A();  // 关键任务1
    Task_B();  // 关键任务2
    Task_C();  // 关键任务3

    // 所有任务都跑完了，证明系统健康，可以喂狗
    HAL_IWDG_Refresh();
}

👉 原则：只有当整个主循环完整执行一遍后，才允许喂狗。

进阶玩法：加入“健康标志位”机制

uint8_t system_healthy = 1;

// 各任务中检测异常
void Task_A(void) {
    if (spi_timeout) system_healthy = 0;
}

// 只有全部OK才喂狗
if (system_healthy) {
    HAL_IWDG_Refresh();
} else {
    // 触发自恢复或上报错误
}

这样就能避免“形式主义喂狗”——程序明明挂了，还在机械地续命。

调试时怎么办？总不能每次单步都复位吧？

当然不能！调试阶段开启看门狗简直是噩梦 😵‍💫——你刚停在断点上思考人生，结果一秒钟后系统啪地重启了……

解决办法很简单： 条件编译 ！

int main(void) {
    HAL_Init();

#ifndef DEBUG
    Watchdog_Init();  // Release模式才启用看门狗
#endif

    while (1) {
        // ...
        HAL_IWDG_Refresh();
    }
}

配合IDE中的 -DDEBUG 宏定义，轻松切换模式。发布前去掉宏即可，安全又方便。

如何知道是不是看门狗搞的复位？

有时候设备反复重启，你想查原因？MCU早就给你留了线索。

几乎所有主流芯片都有 复位源标志寄存器 ，比如STM32的 RCC->CSR ：

if (__HAL_RCC_GET_FLAG(RCC_FLAG_IWDGRST)) {
    printf("Last reset caused by IWDG!\n");
    __HAL_RCC_CLEAR_RESET_FLAGS();  // 清除标志
}

结合外部存储（如EEPROM或Flash日志区），你甚至可以记录：
- 重启次数
- 上次运行时间
- 最后执行的任务ID
- 异常代码编号

这些信息对远程设备的故障定位至关重要，相当于给你的产品装上了“黑匣子”✈️。

工程实践建议：别让看门狗变成摆设

很多项目号称“用了看门狗”，但实际上根本起不到作用。以下是几个常见的坑和最佳实践：

问题	后果	建议
喂狗太频繁或位置错误	卡死也能喂狗，失去意义	放在主循环末尾，确保关键任务已执行
超时时间设置过短	正常任务来不及完成就被复位	至少为主循环最大耗时的2~3倍
多任务系统中遗漏喂狗路径	某些分支未喂狗导致误复位	统一管理喂狗逻辑，使用状态机控制
调试时不关闭看门狗	无法单步调试	使用宏开关，DEBUG模式自动禁用
不分析复位原因	重复故障难以排查	记录复位源，支持远程诊断