STM32– 看门狗–介绍、使用场景、失效场景

STM32 中的看门狗（Watchdog Timer，简称 WDG）有两种主要类型：独立看门狗（IWDG） 和 窗口看门狗（WWDG）。它们的喂狗机制各有特点，主要区别如下：

---

1. 独立看门狗（IWDG）

喂狗模式：常规定时喂狗

喂狗方式： 调用 IWDG_ReloadCounter() 函数，在任何时刻都可以重装载计数器，从而避免超时复位。

超时机制： 如果计数器倒计时到 0 且没有及时喂狗，系统会复位。

特点：

喂狗没有时间窗口限制，只要在超时时间之前喂狗即可。

由 内部低速时钟（LSI，约 32kHz） 提供时钟，不依赖主系统时钟。

无法被软件或调试工具停止，一旦启用只能通过硬件复位重启。

优点：

配置简单，适用于通用场景。

独立于主系统时钟（HCLK），可靠性高。

缺点：

无法防止程序在特定时间段反复喂狗（如错误逻辑进入喂狗环）。

---

2. 窗口看门狗（WWDG）

喂狗模式：窗口限制喂狗

喂狗方式： 调用 WWDG_SetCounter() 函数时，喂狗必须在指定的时间窗口内完成。

窗口时间是由 WWDG 的计数器和窗口寄存器共同决定的。

如果喂狗太早（计数器值大于窗口值）或太晚（计数器倒计时到 0），系统会复位。

超时机制：

必须在窗口时间内重装载计数器。

超过窗口的时间范围（太早或太晚）都会导致复位。

特点：

使用 APB1 时钟（PCLK1） 提供时钟源，依赖主系统时钟。

可以通过调试工具暂停计数。

可设置窗口值，要求喂狗在特定时间范围内完成，防止程序因逻辑错误频繁喂狗。

优点：

增强程序可靠性，防止错误逻辑无限循环喂狗。

支持更精确的复位条件控制。

缺点：

配置稍复杂，需要合理选择窗口值和计数器初始值。

依赖主系统时钟，可靠性略低于 IWDG。

---

两种模式的对比

特性	独立看门狗（IWDG）	窗口看门狗（WWDG）
时钟来源	内部低速时钟（LSI，32kHz）	APB1 时钟（PCLK1）
喂狗机制	任何时间都可以喂狗	必须在时间窗口内喂狗
配置复杂度	简单	较复杂
适用场景	通用场景，保证基本的系统稳定性	高可靠场景，防止逻辑错误频繁喂狗
可靠性	更高	略低，依赖主系统时钟
调试控制	不可暂停	支持暂停
可控性	不限制喂狗时间	支持细粒度时间窗口控制

---

选择建议

1. 使用场景简单，侧重可靠性：选择 独立看门狗（IWDG）。

2. 如在嵌入式系统中需要一个独立于系统时钟的简单复位保护机制。

3. 高可靠性要求，需防止逻辑错误：选择 窗口看门狗（WWDG）。

4. 如工业控制场景，程序卡死可能导致危险，需要精确控制喂狗行为。

---

代码示例

1. 独立看门狗喂狗

#include "stm32f10x_iwdg.h"

void IWDG_Init(void) {
    RCC_LSICmd(ENABLE); // 启用 LSI 时钟
    while (!RCC_GetFlagStatus(RCC_FLAG_LSIRDY)); // 等待 LSI 就绪

    IWDG_WriteAccessCmd(IWDG_WriteAccess_Enable); // 使能配置
    IWDG_SetPrescaler(IWDG_Prescaler_64);        // 设置预分频器为 64
    IWDG_SetReload(625);                         // 设置重装载值（1 秒超时）
    IWDG_ReloadCounter();                        // 加载值到计数器
    IWDG_Enable();                               // 启动 IWDG
}

void Feed_Dog(void) {
    IWDG_ReloadCounter(); // 喂狗
}

/*上下两种初始化和使用，没有关系*********************/

//在main函数中的使用初始化看门狗，不同库函数，初始化函数不一样
// 启用 LSI 时钟,看门狗要用
    RCC_LSICmd(ENABLE);
    while (RCC_GetFlagStatus(RCC_FLAG_LSIRDY) == RESET); // 等待 LSI 就绪
    // 配置 IWDG，超时时间为 1 秒
    IWDG_Config(IWDG_Prescaler_64, 625);
    printf("初始化初始化喂狗\n");


// 定时喂狗，防止复位，放在while循环里面
IWDG_ReloadCounter();
printf("喂狗\n");

2. 窗口看门狗喂狗

#include "stm32f10x_wwdg.h"

void WWDG_Init(void) {
    RCC_APB1PeriphClockCmd(RCC_APB1Periph_WWDG, ENABLE); // 启用 WWDG 时钟

    WWDG_SetPrescaler(WWDG_Prescaler_8);       // 设置预分频器
    WWDG_SetWindowValue(80);                   // 设置窗口值（喂狗窗口）
    WWDG_Enable(100);                          // 启动 WWDG 并设置计数器值
}

void Feed_Dog(void) {
    WWDG_SetCounter(100); // 喂狗（需在窗口时间内）
}


还没有使用过，用的时候再说

通过对比，可以根据实际场景选择合适的看门狗类型并合理设置喂狗机制。

看门狗使用场景

在嵌入式系统中，看门狗的主要目的是检测系统异常并自动复位，保障系统的稳定运行。以下是常见需要喂狗的场景：

---

1. 系统可能出现死循环或卡死的场景

现象：

系统因软件错误、逻辑陷阱或资源争用导致无限循环或停止响应。

应用：

工业自动化控制（PLC 等）。

智能家居设备（如网关、传感器）。

通信设备（如路由器、交换机）。

原因： 看门狗可以在系统卡死时触发复位，避免长时间停机。

---

2. 系统存在较高可靠性要求的场景

现象：

嵌入式设备长时间无人值守，需要保持长期稳定运行。

应用：

医疗设备（监护仪、输液泵）。

交通设备（信号灯控制、车载 ECU）。

军事和航空航天设备。

原因： 使用看门狗复位系统，可提高容错能力和整体可靠性。

---

3. 外设数据采集或处理超时的场景

现象：

数据采集模块长时间未能完成任务，可能导致整个系统响应缓慢或失效。

应用：

数据采集终端（温度、压力传感器）。

多任务实时系统（RTOS）。

原因： 配合看门狗的定期复位机制，避免单个模块卡死影响整体系统。

---

4. 系统通信异常的场景

现象：

外部设备或模块因通信中断而停止响应。

应用：

网络设备（IoT 网关、通信模组）。

智能设备（摄像头、机器人）。

原因： 如果通信超时，看门狗可复位系统重新尝试连接。

---

5. 电磁干扰或外界环境影响较大的场景

现象：

嵌入式设备可能受到环境干扰（电磁干扰、静电等），导致系统异常。

应用：

工业环境（高压设备、变电站）。

军用电子设备。

原因： 看门狗可检测因环境干扰导致的系统失效并触发复位，恢复正常运行。

---

6. 软件升级或运行复杂任务的场景

现象：

系统执行复杂的算法或升级任务时，可能发生资源争用或异常。

应用：

在线升级固件的 IoT 设备。

人工智能推理设备（如车载计算机）。

原因： 看门狗可以监控长时间任务运行，避免任务因不可预测的问题导致系统停滞。

---

7. 用户无法频繁维护设备的场景

现象：

设备分布在偏远或不便维护的位置。

应用：

太阳能监控设备。

海上浮标、地震监测设备。

无人机、卫星等。

原因： 看门狗自动复位功能降低了人工干预的频率，提升系统可用性。

---

8. 高安全性场景

现象：

系统的异常可能带来严重后果（如数据丢失或生命危险）。

应用：

银行 ATM 系统。

医疗设备。

车辆控制系统（自动驾驶）。

原因： 看门狗能在意外时快速恢复系统，避免造成重大损失。

---

总结：典型需要喂狗的场景

场景	主要原因	示例应用
死循环或逻辑卡死	防止程序因意外逻辑错误停滞	工业设备、智能终端
高可靠性要求	长期无人值守，需自我修复	医疗设备、交通控制
数据采集或超时控制	模块运行超时可能影响整个系统	RTOS 系统、数据采集设备
通信异常	网络或模块中断可能影响设备响应	路由器、物联网设备
电磁干扰环境	环境干扰可能引起系统故障	工业控制、军事设备
复杂任务或软件升级	防止任务中断导致系统不可恢复	人工智能设备、在线升级
无法维护的设备	减少人工维护频率，提高设备可靠性	远程监控设备、无人机
高安全性需求	确保关键设备在故障时快速恢复	ATM 机、自动驾驶系统

在这些场景中，合理配置看门狗的超时时间和喂狗逻辑，可以有效提升系统的健壮性和可靠性。

看门狗失效的场景

理论上，看门狗是一种硬件模块，独立于主处理器运行，设计上可以在系统卡死时强制复位。但在某些特殊情况下，即使有看门狗，也可能无法复位。这种情况通常与硬件设计或系统架构有关。以下是可能的原因和解决方法：

---

1. 系统进入低功耗模式

原因：

有些嵌入式设备在进入深度睡眠模式时，会关闭看门狗定时器。

如果设备卡死在低功耗模式中，看门狗无法触发复位。

解决方法：

确保看门狗模块在低功耗模式下仍保持工作（某些芯片支持此功能）。

使用独立看门狗（如外部硬件看门狗），保证看门狗与主处理器的运行无关。

---

2. 系统总线或时钟停止工作

原因：

系统因为严重错误（如总线死锁或时钟停止），导致看门狗依赖的时钟源失效。

解决方法：

使用内部低速时钟（如独立的低速振荡器 LSI）驱动看门狗。

确保时钟源具有高可靠性，并在设计中添加冗余机制。

---

3. 电源故障

原因：

硬件因供电不足或瞬间断电，导致看门狗和主处理器均停止工作。

解决方法：

添加稳压电路和电源监控芯片，确保系统供电稳定。

使用外部看门狗模块，其独立供电可提升可靠性。

---

4. 看门狗配置或逻辑错误

原因：

看门狗初始化错误或喂狗逻辑未正确实现，导致看门狗无法正常运行。

误配置过长的超时时间，程序卡死后仍在喂狗。

解决方法：

充分测试看门狗初始化和喂狗逻辑。

使用合理的超时时间，避免因喂狗间隔过长或喂狗频率过高而失效。

---

5. 硬件设计缺陷

原因：

某些硬件设计中，看门狗复位信号未正确连接或复位信号不起作用。

外部硬件看门狗模块未正确实现逻辑复位。

解决方法：

确保看门狗复位信号正确连接到处理器的复位引脚。

测试硬件设计的复位功能是否正常。

---

6. 看门狗自身故障

原因：

看门狗模块内部硬件故障，导致其无法工作。

例如独立看门狗的振荡器损坏或芯片老化。

解决方法：

定期检测和维护设备，确保硬件正常。

使用多个看门狗模块（例如内部和外部看门狗结合）。

---

7. 看门狗复位后依旧死循环

原因：

程序设计问题导致复位后重复进入死循环，触发看门狗再次复位。

解决方法：

复位后执行硬件自检和初始化，避免问题反复发生。

在看门狗超时后，将复位状态记录在非易失性存储器中，方便分析问题根源。

---

8. 极端硬件或环境问题

原因：

硬件遭受极端环境干扰（如高强度电磁辐射、雷击）。

存在硬件级别的设计缺陷或材料老化。

解决方法：

提升设备抗干扰能力，例如添加屏蔽罩、滤波器。

定期更新设备，避免使用超出寿命的硬件。

---

如何降低看门狗失效的可能性

1. 设计冗余系统：
2. 使用多个独立的看门狗模块，主从备份。
3. 合理选择看门狗类型：
4. 使用独立看门狗（如外部芯片）而非依赖于主处理器的内部看门狗。
5. 测试看门狗功能：
6. 定期在程序中模拟卡死场景，验证看门狗是否能正常复位。
7. 使用外部复位电路：
8. 配合电源管理芯片（如带复位功能的电源监控芯片），提供额外的复位保障。
9. 做好复位后程序设计：
10. 确保复位后系统能进入正常工作状态，避免重复复位。

---

总结

虽然看门狗是一种非常可靠的保护机制，但它并不是万能的。如果系统设计或硬件环境存在问题，看门狗也可能无法复位。通过合理设计、冗余机制和充分测试，可以最大程度地降低看门狗失效的风险。

作者：code_snow