原标题：ARM开发中的软、硬件看门狗

在 ARM 开发中，看门狗（WatchDog Timer, WDT） 是保障系统可靠性的核心机制，分为 硬件看门狗 和 软件看门狗 两种类型。它们通过监控系统运行状态，在检测到异常时触发复位或中断，防止系统因软件故障（如死循环、无限阻塞）而失控。以下从原理、特点、应用场景及优化实践等方面详细对比分析：

一、硬件看门狗

1. 核心原理

• 独立硬件模块：
  集成在 ARM 芯片内部（如 STM32 的 IWDG、NXP Kinetis 的 WWDT），由独立时钟源（如低速内部振荡器 LSI）驱动，与主系统时钟解耦。

• 计数器机制：
  硬件计数器递减计数，系统需在计数器归零前通过写入特定值（喂狗）重置计数器。若超时未喂狗，触发 硬件复位信号（如 RESET 引脚拉低），强制重启系统。

• 不可屏蔽性：
  复位信号优先级高于所有中断，即使 CPU 挂死或中断系统崩溃，硬件看门狗仍能工作。

2. 关键特点

• 高可靠性：
  独立时钟和硬件逻辑确保在极端情况下（如主时钟故障、代码跑飞）仍能触发复位。

• 低配置复杂度：
  通常仅需设置超时时间（通过预分频和重装载值），无需软件复杂逻辑。

• 典型应用场景：

• 工业控制器、汽车电子（如 ECU）、医疗设备等对可靠性要求极高的场景。

• 无操作系统（Bare-metal）或简单 RTOS 的系统。

3. 局限性

• 灵活性不足：
  超时时间固定，难以动态调整；喂狗时机需严格匹配主程序执行周期。

• 无法区分故障类型：
  无论死循环、中断阻塞还是硬件故障，均触发统一复位，缺乏故障诊断信息。

4. 优化实践

• 双硬件看门狗：
  部分芯片（如 STM32H7）支持 独立看门狗（IWDG） 和 窗口看门狗（WWDG） 协同工作，前者防止系统完全挂死，后者检测喂狗时机是否合理。

• 复位后自检：
  在复位处理函数中记录复位原因（如通过寄存器标志位），并结合 EEPROM 或 Flash 存储故障日志。

二、软件看门狗

1. 核心原理

• 软件模拟计数器：
  利用系统定时器（如 SysTick）或通用定时器（TIM）实现计数器功能，通过中断服务程序（ISR）检测喂狗标志位。

• 喂狗逻辑：
  主程序或关键任务定期更新喂狗标志位，软件定时器检查标志位是否超时。若超时，触发 软件复位（如调用 NVIC_SystemReset()）或进入安全模式。

2. 关键特点

• 高灵活性：

• 可动态调整超时时间（如根据系统负载或任务优先级变化）。

• 支持多级喂狗策略（如关键任务单独喂狗，非关键任务共享喂狗）。

• 依赖主系统：
  若主程序完全挂死（如陷入死循环且未触发中断），软件看门狗可能失效。

• 典型应用场景：

• 复杂操作系统（如 Linux、FreeRTOS）中，作为硬件看门狗的补充。

• 需精细控制喂狗时机的场景（如动态调整超时时间以适应不同任务）。

3. 局限性

• 可靠性低于硬件看门狗：
  依赖主系统时钟和中断机制，若中断系统崩溃，软件看门狗无法工作。

• 实现复杂度高：
  需手动处理喂狗逻辑、超时处理和任务同步，增加代码复杂度。

4. 优化实践

• 硬件+软件协同看门狗：

• 硬件看门狗作为最终保障，软件看门狗用于检测逻辑错误（如任务超时）。

• 示例：在 FreeRTOS 中，软件看门狗监控任务堆栈溢出或死锁，硬件看门狗防止系统完全挂死。

• 心跳机制结合：

• 关键模块定期发送“心跳”信号（如更新共享变量），软件看门狗检测心跳是否超时。

• 适用于分布式系统或模块化设计。

三、硬件看门狗 vs 软件看门狗：对比总结

四、选型建议

1. 优先选择硬件看门狗：

• 适用于 无人值守、高可靠性 场景（如远程监控设备、汽车电子）。

• 简单系统（如无操作系统）中，硬件看门狗是唯一可靠选择。

2. 补充软件看门狗：

• 在复杂系统（如 Linux、RTOS）中，软件看门狗可检测逻辑错误（如任务死锁、堆栈溢出）。

• 结合硬件看门狗形成 双层保护，提升系统容错能力。

3. 避免单一依赖：

• 切勿仅依赖软件看门狗，尤其在安全关键场景中，硬件看门狗是最后防线。

五、总结

• 硬件看门狗 是 ARM 开发中的“保底机制”，以独立性和可靠性为核心优势，适合简单但高可靠性的场景。

• 软件看门狗 是“逻辑监控层”，通过灵活性弥补硬件看门狗的不足，适合复杂系统中的精细化故障检测。

• 最佳实践：在大多数 ARM 系统中，硬件+软件看门狗协同工作 是最优解，兼顾可靠性与灵活性。