2、看门狗复位机制：复位信号的产生、喂狗操作详解、超时时间计算与配置

看门狗这东西，说白了就是一个「定时炸弹」。你必须在规定时间内去拆弹（喂狗），否则它就炸给你看——把整个系统复位掉。我刚开始做嵌入式那会儿，总觉得看门狗就是个累赘，后来在量产阶段吃过一次亏，才真正重视起来。

2.1 复位信号是怎么产生的？

看门狗的核心，是一个独立运行的硬件计数器。这个计数器一旦启动，就会从某个初始值开始，一直往下减。减到零的时候，它就会拉出一个复位信号。

这个复位信号，通常有两种形式：

• 内部复位：直接复位芯片内部逻辑，不拉外部引脚。我见过不少MCU用这种方式，优点是快，缺点是调试时很难抓到现场。
• 外部复位：通过一个专用的WDT复位引脚，拉低外部电路。这种信号更「暴力」，连外设一起复位，适合对可靠性要求极高的场景。

嗯，这里要注意：复位信号不是瞬间消失的。它通常会持续几个时钟周期，确保所有寄存器都回到初始态。我在一个项目中遇到过复位信号脉宽不够，导致部分外设没复位干净，系统跑起来就乱跳。后来查了芯片手册，才发现是配置寄存器里有个复位脉宽选项没设对。

2.2 喂狗操作详解

喂狗，就是往看门狗定时器里写一个特定值，让它重新开始计数。说白了就是告诉它：「我还活着，别复位我。」

喂狗操作一般分两步：

1. 解锁：先写一个解锁序列（比如0x55、0xAA），防止误操作。
2. 喂狗：再写一个重装载值，计数器就从这里重新开始减。

我个人的习惯是，把喂狗操作封装成一个函数，放在主循环的固定位置。但要注意，不能放在中断里喂狗——你想想看，如果主程序已经卡死了，中断还在跑，那看门狗就永远喂不饱，系统死锁了也检测不到。

我曾经在一个项目里，把喂狗放在了定时器中断里。结果主程序因为一个死循环卡住了，中断却还在正常触发，看门狗一直喂得饱饱的。直到客户反馈设备死机，我才意识到这个坑。从那以后，我再也不在中断里喂狗了。

2.3 超时时间计算与配置

超时时间，就是看门狗从开始计数到触发复位的时间。这个时间怎么算？其实很简单：

超时时间 = 重装载值 × 时钟周期

举个例子，假设看门狗时钟是32kHz，重装载值是1000：

时钟周期 = 1 / 32000 ≈ 31.25 μs
超时时间 = 1000 × 31.25 μs = 31.25 ms

也就是说，你必须在31.25毫秒内喂一次狗，否则系统就会被复位。

配置超时时间时，我一般遵循两个原则：

• 不能太短：太短的话，正常流程稍微慢一点就触发复位，系统会频繁重启。我记得有个项目，看门狗设了10ms，结果一次I2C通信超时就把系统复位了，调试起来非常痛苦。
• 不能太长：太长的话，系统死锁了要等很久才复位，用户体验极差。工业设备我一般设1~3秒，消费类产品可以短一些，500ms左右。

另外，不同芯片的看门狗配置方式也不一样。有些是直接写寄存器，有些是通过配置位来选预分频。我建议你拿到芯片手册后，先找到看门狗章节，把时钟源和分频系数搞清楚。不然算出来的时间跟实际跑出来的时间对不上，那就尴尬了。

时钟频率	重装载值	超时时间	适用场景
32 kHz	500	15.6 ms	高速响应
32 kHz	4000	125 ms	一般控制
32 kHz	32000	1 s	工业设备
1 MHz	1000000	1 s	高性能场景

嗯，最后说一句：看门狗不是万能的。它只能检测到「程序跑飞」或「死循环」这类问题，对于逻辑错误、数据错误，它无能为力。所以别指望靠看门狗解决所有问题，它只是最后一道防线。