1. 看门狗到底是个什么东西
1.1 从一次程序跑飞的经历说起
做嵌入式开发的人，十有八九都遇到过这样的情况：设备在实验室里跑得好好的，一上现场就三天两头死机。按键没反应，屏幕不动了，通信也断了。你插上调试器一看，程序指针不知道飞到哪个地址去了，全部变量乱成一锅粥。拔电重启，又好了。过两天又犯病。
这种问题在工业现场尤其常见。电机启动时的大电流干扰、变频器的强电磁噪声、电源波动，都可能让MCU内部逻辑混乱。芯片本身不会凭空烧坏，但程序一旦跑飞，就再也回不到正常的执行流里来。没有外部干预的情况下，设备只能一直“死”在那里，直到有人手动断电重启。
看门狗（WDT，WatchDog Timer）就是为了解决这个问题而生的。它的核心思路非常朴素：让MCU每隔一段时间必须证明自己还活着，如果超时没有回应，就强制将整个芯片复位，让程序从头开始运行。这样一来，即使程序真的跑飞了，设备也能在最短时间内自我恢复，而不是等人去现场断电。
这篇文章要讲的就是看门狗的原理、分类和实际应用。不管你是刚接触单片机的学生，还是被项目折磨的开发工程师，看门狗都是一项绕不开的基础技能。掌握它，你的设备可靠性会提升一个档次。
1.2 看门狗的底层机制：计数器、喂狗与复位
看门狗的本质，其实就是一个硬件计数器。这个计数器从上电开始就不断地递减，减到零就会触发一次系统复位。正常情况下，主程序需要在计数器减到零之前，主动把它重新装填成一个较大的值。这个重新装填的动作，业内俗称“喂狗”。
可以把它想象成一个小区的夜间巡更制度。保安拿着一个巡更棒，每隔一个小时必须到某个打卡点刷一次卡，证明自己还在正常巡逻。如果两个小时都没人刷卡，监控中心就知道出事了。看门狗就是这个“监控中心”，喂狗就是保安“刷卡”。程序正常运行时，主循环里的喂狗指令会规律地执行；一旦程序卡死，喂狗指令自然执行不到，计数器一路减到零，复位信号随之而来。
这里有几个关键的设计细节需要注意。第一，看门狗一旦启动，通常就不能再关闭，只有复位才能重置它。这保证了即使程序因为故障跑到了奇怪的代码路径，也无法“顺手”把看门狗关掉。第二，喂狗操作本身要尽可能简单，不能依赖复杂的外设逻辑。如果喂狗之前还要等一个串口数据传完，那看门狗就失去了它应有的可靠性。第三，计数器用的是独立的时钟源，一般是一个RC振荡器，与主系统时钟相互独立。即使主时钟停振，看门狗依然能工作，这也是它能在“死机”状态下仍发挥作用的前提。
从复位方式上看，看门狗产生的复位与手动按复位键的效果是等同的，芯片会重新从启动文件中的复位向量开始执行。对于运行RTOS的系统，复位后一切重新初始化，系统回到一个已知的、可控的状态。
2. 看门狗的类型选择：独立看门狗、窗口看门狗与软件看门狗
2.1 独立看门狗：原理、时钟与特性
独立看门狗是最常见的一种，它由芯片内部一个完全独立的时钟源驱动，通常是一个低频RC振荡器，频率在32kHz到40kHz之间。在STM32系列中，这个时钟叫LSI；在NSUC1612E中，也有一路专门供看门狗使用的内部低速时钟。
之所以叫“独立”，是因为它不依赖主系统时钟。主时钟停振了，看门狗照样计时；主程序跑飞了，看门狗照样倒数计数。这就保证了它能在系统异常时，独立地完成复位任务。
独立看门狗的使用要点在于超时时间的设置。以NSUC1612E为例，其看门狗预分频器有多个档位，配合重载寄存器，可以覆盖从几百微秒到几十秒的溢出时间。实际项目中，超时时间的选择很有讲究，不能拍脑袋随便定一个值。太短了，正常流程稍微慢一点就可能误复位；太长了，系统异常后恢复时间太久，设备“死机”的时间也会相应变长。
通常我会把看门狗超时设置为正常喂狗周期的5到10倍。比如主循环跑一遍需要50ms左右，那我喂狗间隔就设为100ms，看门狗超时设为500ms以上。这样的余量足以应对任务调度偶尔的抖动，又能保证在程序卡死后的半秒内完成复位。
2.2 窗口看门狗：为什么多了上窗口和下窗口
窗口看门狗与独立看门狗最大的不同在于，它不只限制“最晚喂狗”的时间，还限制了“最早喂狗”的时间。喂狗动作必须发生在一个由上下窗口限定的时间段内，喂早了会复位，喂晚了也会复位。
这就好像巡更制度升级了：不仅要求保安必须在规定时间内打卡，还要求不能刚到点位就打卡走人，巡逻的时间不能太短。如果你的保安两分钟前刚从这里经过，两分钟后又来打卡，显然不正常——很可能是他根本没认真巡逻。
窗口看门狗存在的意义，是为了应对一种更隐蔽的故障模式：程序并没有完全跑飞，而是部分逻辑失效了，比如某个中断被频繁触发，导致主循环一直在处理中断任务，看起来系统还在“运行”，但实际业务已经停摆了。独立看门狗在这种情况下可能感受不到异常，因为只要喂狗代码还能执行到，计数器就一直在重新装填。而窗口看门狗要求喂狗必须发生在特定的时间窗口内，如果主循环执行频率异常加快，导致喂狗时间落在上窗口之前，系统同样会被复位。
从应用角度讲，独立看门狗适合检测“程序死了”这种粗粒度异常，窗口看门狗适合检测“程序没死但跑偏了”这种细粒度异常。如果能同时使用两种看门狗，可靠性会更上一层楼。不过对于大多数MCU来说，IWDG和WWDG往往是二选一或者可以同时启用但配置复杂，具体看项目需求。
2.3 软件看门狗是怎么工作的
硬件看门狗解决的是MCU级别的异常，但有些业务场景下，程序在正常运转，MCU也没有跑飞，只是某个关键任务卡住了。比如在一个多任务系统中，通信协议栈的任务因为等待一个永远等不到的信号量而阻塞，而喂狗操作恰好由这个任务负责，那系统一样会复位。但有些情况下，喂狗的不是这个任务，那么硬件看门狗就感知不到通信任务已经死了。
这时候就需要软件看门狗。它的实现方式灵活多变，通常做法是维护一个计数变量和几个“任务心跳标志”。每个关键任务在自己的循环里定期置位一个标志，一个专门的监控任务检查所有标志是否按预期更新。如果发现某个任务超时未置位，就主动触发软件复位，或者记录日志后报警。
软件看门狗的优点是粒度很细，可以精确到每个任务、每个功能模块。缺点是它依赖其他任务正常工作——如果整个调度器都崩溃了，软件看门狗本身也可能跟着瘫痪。所以正规的工程实践中，软件看门狗通常是作为硬件看门狗的补充，而不是替代。
2.4 三种看门狗的选型对比
| 类型 | 时钟源 | 检测粒度 | 喂狗窗口限制 | 适用场景 |
|---|---|---|---|---|
| 独立看门狗 | 独立RC振荡器 | 仅检测主流程是否跑飞 | 无，只能晚不能早 | 通用产品，防止长时间死机 |
| 窗口看门狗 | 系统时钟分频 | 检测异常的执行频率 | 有，太早太晚都复位 | 对程序执行时序有严格要求的场景 |
| 软件看门狗 | 由OS调度驱动 | 可精确到任务级 | 无，通常只设超时 | RTOS多任务系统，业务完整性检测 |
选型上没有绝对的标准答案，但有一个基本思路可以参考：如果你的系统跑的是裸机程序，只有一个主循环和几个中断，独立看门狗基本够用。如果你的系统对安全要求较高，比如控制电机、驱动加热器，或者程序执行时序一旦错乱就可能造成危险，窗口看门狗更合适。如果你的系统上了RTOS，软件看门狗几乎是必备的，但别忘了它后面还需要硬件看门狗兜底。
3. 超时时间计算与喂狗程序设计
3.1 超时时间是怎么算出来的
看门狗超时时间 = 预分频器分频系数 × 重装载值 ÷ 看门狗时钟频率。这是一个很简单的公式，但实际配置时不少人会算错。这里以NSUC1612E为例，拆解一下完整的计算过程。
假设NSUC1612E的内部低速时钟为32kHz，预分频器设置为8分频，那么喂狗时钟就是32kHz ÷ 8 = 4kHz。如果重装载值设置为1000，那么溢出时间就是1000 ÷ 4000 = 0.25秒，即250ms。
实际写代码时，我更习惯反过来算。先确定项目允许的最长复位时间，再反推预分频器和重装载值。比如某设备要求异常恢复时间不超过2秒，看门狗时钟32kHz，我选择预分频32分频，得到1kHz的喂狗时钟，那么重装载值设为2000，溢出时间就是2秒。这个配置下，喂狗间隔要低于2秒，通常我会取1秒喂一次，留有100%的余量。
3.2 喂狗的黄金位置：在哪里喂狗最可靠
喂狗位置的选择直接决定了看门狗的保护效果。很多新手的习惯是“主循环末尾喂狗”，这在简单裸机程序里没问题，但在复杂系统中可能会出大问题。
举个真实的例子。一个用STM32F103做的数据采集设备，主循环里有三个任务：采样、LCD刷新、串口通信。如果只把喂狗放在主循环最后，那么当某个阻塞操作卡住时，主循环后面部分的代码都执行不到，看门狗会复位。但如果串口通信使用了阻塞式发送，发送大数据时主循环卡在发送函数里，这时看门狗也可能误复位——因为程序并没有异常，只是发送时间超出了看门狗周期。
解决这个矛盾有两个思路。第一个思路是把喂狗放到一个定时器中断里，以固定的频率喂狗，主循环卡住时中断仍然能触发喂狗，系统不会复位。但这有个致命缺陷：如果主循环真的跑飞了，中断还在正常喂狗，看门狗就完全失去作用了。所以我强烈不建议在中断里喂狗，除非你设计的业务逻辑能够接受“中断正常但任务卡死”这种状态。
第二个思路是分层次喂狗。主循环里喂狗，同时每个重要任务执行完毕时也喂一次，喂狗操作本身用函数封装，内部将重装载值重新写入寄存器。这样即使某个任务卡的久了点，其他任务正常执行时也会喂狗，不会被误复位。同时，如果所有任务都卡了，主循环的喂狗也会停，看门狗依然能起到兜底作用。
3.3 多任务环境下喂狗的策略
在RTOS环境里，喂狗策略比裸机更讲究。我见过的失败案例中，最常见的是“每个任务都喂狗”和“专门一个任务喂狗”两种极端。
每个任务都喂狗的问题在于，只要任何一个任务还在跑，看门狗就不会复位。假设系统里有三个任务，其中两个已经死了，剩下一个还活着并且负责喂狗，那么这个系统就等于没有看门狗保护。
专门一个任务喂狗的问题则在于，如果这个任务因为优先级低于某个繁忙的实时任务而长期得不到调度，看门狗就会误复位。尤其在抢占式调度器中，一个高优先级任务如果写了个死循环，低优先级的喂狗任务根本得不到CPU时间。
相对稳妥的做法是“心跳汇聚”模式：每个任务在自己的主循环里递增一个任务级计数器，喂狗任务周期性地检查这些计数器是否在递增，如果全部正常，才执行真正的喂狗操作，并且把计数器清零。一旦发现某个任务计数器停更了，喂狗任务可以不喂狗，让硬件看门狗触发复位，或者主动调用复位函数并记录复位原因。这种模式兼顾了任务级异常检测和硬件级兜底，实际项目中表现很稳定。
4. 看门狗的典型应用场景
4.1 工业控制：PLC和电机驱动器
工业控制是看门狗应用最刚性、要求最苛刻的领域。PLC（可编程逻辑控制器）在工厂里可能要连续运行数年不关机，环境里满是电磁干扰、电压波动、温度变化。主轴电机一启动，现场的浪涌电流常常达到几十安培甚至更高，瞬间的电磁脉冲足以让控制板上的信号线耦合出虚假的干扰信号。看门狗是这些设备能在恶劣环境下保持可靠运行的基石之一。
电机驱动器领域尤其依赖窗口看门狗。为什么不是普通独立看门狗？因为电机控制对PWM波形的时序要求极其严格，如果控制程序因为某个异常分支而提前进入了PWM更新代码段，IGBT的开关时序就可能错乱，轻则电流畸变，重则炸机。独立看门狗只能保证“程序没死”，窗口看门狗则能保证“程序运行的节奏正确”，这正好契合电机控制的痛点。
还有一类重要应用是通信网关。工业现场的RS485总线、Profibus、Modbus等协议，通信一旦中断，整个产线都可能停机。网关设备内的看门狗能够保证通信模块卡死后自动复位恢复，把单点故障的影响降到最低。
4.2 汽车电子：车身控制器与BMS
汽车电子对可靠性的要求是“功能安全”，这是一个系统工程，看门狗只是其中一环，但它依然不可或缺。车身控制器（BCM）负责车窗升降、门锁控制、灯光控制等功能，如果控制器死机，车窗可能卡在半路、门锁可能失灵，用户会直接投诉，甚至会引发安全风险。
电池管理系统（BMS）对看门狗的应用更有代表性。BMS的主要任务是监测每一节电池的电压和温度，并控制充电和放电的MOS管通断。如果主控芯片死机，而充电MOS管正好处于导通状态，电池就可能过充，后果无法承受。因此BMS的设计中，除了硬件看门狗外，还有一套独立的安全监控芯片，形成“双保险”。即使MCU上的看门狗失效了，外部安全芯片也能在超时后直接切断充电回路。
汽车电子里还有一个特殊之处：功能安全标准要求看门狗自身也要满足一定的诊断覆盖率。也就是说，不能只配置一个看门狗然后就不管了，还要定期验证看门狗的功能是否正常。常见的做法是在软件中设置一个测试标志，每次喂狗时检查重装载值是否写入成功，如果连续多次失败，则主动进入安全状态。
4.3 消费电子产品：智能家电与电动工具
消费电子对看门狗的要求没有工业和汽车那么苛刻，但用户对体验的敏感度很高。我拆过几款智能电饭煲的电路板，主控芯片上基本都外挂了或内部集成了看门狗功能。原因很简单：电饭煲如果在煮饭过程中死机，加热器一直通电，米饭烧糊是小，引发火灾是大。哪怕只是偶尔一次，品牌方也承担不起这样的风险。
电动工具是另一个典型应用。锂电钻、角磨机这类设备，工作环境粉尘大、振动大、温度高，PCB上的焊点都可能因为长期振动而出现虚接。看门狗在这里的作用是应对“软故障”——程序因电源干扰或振动导致跑飞后，设备能自行复位。对用户来说，最多感觉某一瞬间电钻顿了一下，但比起彻底死机需要插拔电池，体验上完全不是一个级别。
智能家居里的WiFi模块和主控之间的通信也经常用看门狗来做“握手”。主控启动WiFi模块后，如果模块在设定时间内没有返回初始化完成报文，主控就复位WiFi模块重新初始化。这是一种另类的看门狗用法——不是保护主控自身，而是用超时机制保护外部设备的正常启动。
5. NSUC1612E 看门狗配置实战
5.1 NSUC1612E的WDT模块概述
NSUC1612E是国民技术旗下一款基于ARM Cortex-M0+内核的MCU，主频可以做到64MHz，片内集成丰富的外设资源，在国产替代的大背景下用得越来越广。它的WDT模块设计得比较规整，既有独立看门狗的功能，也支持窗口模式，可以灵活适配不同场景。
NSUC1612E的WDT有几个值得注意的特性。一是它支持在待机模式下继续运行，这对于低功耗应用是个好消息——设备休眠时看门狗依然在计数，主控在唤醒后需要先判断是否发生了看门狗复位，再做相应的恢复处理。二是它的喂狗寄存器有写保护机制，需要先写入解锁键值才能更新配置，防止程序跑飞时意外修改看门狗配置。
这里要我提前说明一下：不同批次、不同封装的NSUC1612E，外设寄存器的基地址可能有差异，下面的代码示例基于该系列MCU的典型寄存器结构编写，具体使用时请务必以官方数据手册为准。但配置流程和思路是通用且可参考的。
5.2 寄存器配置与代码实现
看门狗配置的核心步骤可以拆成四步：解锁写保护、设置分频系数和重装载值、开启窗口模式（如果使用）、启动看门狗。
先看基础配置的代码，用轮询方式实现喂狗：
#include "nsuc1612e_wdt.h" // 喂狗操作：向重装载寄存器写入新的计数值 void wdt_feed(void) { // 写解锁键，使重装载寄存器可写 WDT->KEY = 0xA5; // 重新装载计数值 WDT->LOAD = WDT_LOAD_VALUE; } // 初始化看门狗 void wdt_init(uint32_t timeout_ms) { // 1. 解锁寄存器配置 WDT->KEY = 0xA5; // 2. 设置预分频系数，这里假设时钟源为32kHz // 预分频8，则计数时钟为4kHz WDT->CR &= ~(0x07 << WDT_CR_PR_Pos); WDT->CR |= (0x02 << WDT_CR_PR_Pos); // 3. 计算重装载值 // 计数时钟 = 32k / 8 = 4kHz // 超时时间 = 计数周期数 / 计数时钟频率 uint32_t load = (uint32_t)(timeout_ms * 4); WDT->LOAD = load; // 4. 启动看门狗 WDT->CR |= (1 << WDT_CR_WDE_Pos); }这段代码里最关键的参数就是timeout_ms乘以4这一步。4是怎么来的？因为预分频8分频后计数时钟是4kHz，也就是1ms计数4次。如果timeout_ms等于500，那么重装载值就是2000，溢出时间是500ms。
在主循环中调用喂狗就很简单了，但要保证喂狗间隔不超过超时时间的一半：
int main(void) { system_clock_init(); uart_init(); // 初始化看门狗，溢出时间500ms wdt_init(500); while (1) { // 业务代码 do_sensor_sample(); do_lcd_refresh(); // 喂狗：建议放在主循环的固定位置 wdt_feed(); // 延时保持节奏 delay_ms(100); } }5.3 窗口模式配置与实践
如果要启用NSUC1612E的窗口看门狗功能，配置会多一个步骤：设置窗口上限值。这个值限定了喂狗动作可以发生的“最早时刻”。只有计数器的当前值介于0和窗口上限值之间时，喂狗操作才有效。
窗口上限值的单位与重装载值一致，都是计数周期数。举个例子：如果重装载值设为2000（对应500ms），窗口上限值设为1000，那么喂狗动作必须发生在计数器从2000递减到1000之间，也就是前250ms内喂狗是无效的，会触发复位；只有等到计数器递减到1000以后，即时间过半后，喂狗才被接受。
void wdt_init_window(uint32_t timeout_ms, uint32_t window_percent) { WDT->KEY = 0xA5; // 设置预分频系数 WDT->CR &= ~(0x07 << WDT_CR_PR_Pos); WDT->CR |= (0x02 << WDT_CR_PR_Pos); // 计算并写入重装载值 uint32_t load = (uint32_t)(timeout_ms * 4); WDT->LOAD = load; // 计算并写入窗口上限值 // 窗口值 = 重装载值 * (1 - window_percent / 100) uint32_t window = (uint32_t)(load * (100 - window_percent) / 100); WDT->WINDOW = window; // 使能窗口模式 WDT->CR |= (1 << WDT_CR_WWDE_Pos); // 启动看门狗 WDT->CR |= (1 << WDT_CR_WDE_Pos); }窗口模式下的喂狗调用与普通模式一样，但喂狗动作必须在主循环中的固定位置执行，位置太靠前或者太靠后都会出问题。这也是窗口看门狗调试起来比较费劲的地方——初期调试阶段，建议先禁用窗口功能，跑通基本流程后再开启，否则很容易被连续复位打断调试节奏。
6. 常见问题与排查技巧实录
6.1 系统反复复位的排查
看门狗配置完成后，最常见的现象就是系统不断复位。具体表现为：程序可以运行，但运行一小段时间就自动重启，有时候甚至完全无法进入main函数。
排查这种问题，第一步不是怀疑代码逻辑，而是先确定复位源。NSUC1612E的复位状态寄存器会记录最近一次复位的原因，包括上电复位、外部引脚复位、看门狗复位、软件复位等。进入main函数后，立刻读取这个寄存器，打印或者存到掉电保存区里。如果看到看门狗复位的标志位，基本可以断定是喂狗太慢或者喂狗根本执行不到。
第二步是检查喂狗位置。很多人会忽略一个情况：初始化外设的过程可能耗时较长，如果初始化代码里包含了等待外部Flash写入、等待传感器上电稳定等阻塞逻辑，而看门狗在初始化之前就启动了，那么初始化阶段就可能触发复位。解决办法有两个，要么把看门狗初始化放到所有外设初始化之后，要么在耗时较长的初始化步骤中临时喂狗。
第三步是用调试器的断点功能定位。如果系统持续复位，调试器可能很难停在main函数里，因为复位后PC会跳转到启动文件。可以在启动文件的复位向量处打下断点，再单步跟进，观察实际跑到了哪里。这一步对新手来说可能有点复杂，但排查效率很高。
6.2 喂狗太早或太晚导致的异常复位
喂狗太晚导致复位很好理解：主循环里的某个操作耗时超过了看门狗周期。但喂狗太早导致复位的情况，很多新手就不太明白了。这里要区分两种情况：如果用的是独立看门狗，不存在“太早”一说，什么时间喂狗都行，只要不晚于超时时间。如果用的是窗口看门狗，喂狗太早就会触发复位，因为计数器还没有递减到窗口下限以下。
我在一个项目中就踩过这个坑。当时用窗口看门狗保护一个通信任务，窗口设为50%。调试时发现系统启动后始终无法正常运行，后来才发现是在主循环开头就喂狗了。主循环开头时，计数器刚从重装载值开始递减，远没有到窗口内，这一喂狗操作反而触发了复位。把喂狗从主循环开头挪到主循环中间后，问题立刻消失了。
排查这类问题时，可以先把窗口模式关闭，只保留最晚喂狗限制，让系统先跑起来。等基本功能都正常了，再逐渐缩小窗口，直到找到饲狗动作的实际触发范围。这个手法很实用，推荐优先使用。
6.3 低功耗模式下的看门狗处理
低功耗应用和看门狗之间天然存在一些矛盾。MCU进入休眠模式后，CPU停止执行指令，主导循环里的喂狗操作自然也不会执行。如果看门狗还在运行，芯片就会在休眠期间被反复复位，根本无法正常进入低功耗状态。
针对这个问题，不同芯片有不同处理方式。NSUC1612E的看门狗在待机模式下可以配置为继续计数，也可以配置为停止计数。如果你的应用需要在休眠期间保持看门狗保护，可以把看门狗配置为继续运行，然后用一个定时器在休眠前设置好唤醒时间，在唤醒后的第一时间喂狗。否则芯片会在休眠中复位，表现为“定时复位”的诡异现象。
另一种做法是功耗优先，在进入休眠前临时关闭看门狗，醒来后再重新启动。但这里有一个隐患：看门狗关闭期间，如果程序因为某些原因卡死，就失去了保护。稳妥的做法是先备份当前状态，注册一个低功耗唤醒中断，在唤醒处理中立刻完成喂狗，再继续正常业务。这样既保证了休眠时不被复位，醒来后也能快速恢复保护。
还有一种更高级的用法：把看门狗当作低功耗唤醒源之一。休眠前设置较长的看门狗超时时间，正常情况下不会触发；如果程序在预期时间内没有正常唤醒处理业务，看门狗就会把芯片复位，实现故障恢复。
6.4 调试阶段如何临时禁用看门狗
这里必须说一个很多新手都会踩的坑：调试验收时忘记关闭看门狗，导致每次暂停在断点上，过一会儿芯片就自动复位了。调试器一暂停，程序停止执行，看门狗并不能感知到调试状态，照常计数复位。这会给调试带来很大的困扰，尤其是在单步执行的时候。
NSUC1612E和多数Cortex-M内核MCU一样，支持在调试模式下冻结看门狗。在调试器的配置中启用“Debug Freeze”功能，或者通过调试接口访问DBGMCU寄存器，把看门狗时钟冻结。这样调试时暂停程序，看门狗也不会继续计数。
如果芯片不支持这个功能，还有更笨但可靠的办法：在代码里加一个条件编译宏，只有在调试版本中才禁用看门狗启动代码，而发布版本中强制执行完整初始化流程。这要求你在代码中把看门狗初始化封装成一个独立函数，用宏来控制是否调用。我在实际项目里一直是这么做的，不同版本固件用不同的构建配置，互不干扰。
不过要特别注意，发布版本中千万不要保留跳过着门狗初始化的代码路径，哪怕你只是为了解决某个临时bug而临时注释掉。这种事我亲眼见过不止一次：某同事打包量产固件前，注释掉了看门狗初始化函数，结果产品在客户现场死机后无法自恢复，几十台上千台设备需要逐台重新烧录，代价极其惨痛。如果你使用了版本管理工具，建议在发布提交流程中增加一个强制检查项，确保看门狗初始化代码在发布版本中存在。
7. 写在最后：看门狗是设计出来的，不是堆出来的
从我自己的项目经验来看，看门狗的设计往往比代码实现更能体现一个嵌入式工程师的水平。同样一块板子，有人用了看门狗还是经常死机，有人没用外部看门狗，单靠芯片内置的WDT就能在几十毫秒内完成异常恢复。差别就在于对故障模式的理解深度和执行时序的精细把控。
在做看门狗方案时，我一般会先回答三个问题：系统最核心的故障模式是什么，是程序跑飞还是任务卡死还是执行时序错乱？如果发生异常，设备需要在多长时间内完成复位恢复？喂狗操作放在哪里，既能覆盖主要风险，又不会因为业务波动产生误复位？这三个问题想清楚了，看门狗的型号选择、参数配置和代码结构基本就定了。
最后再分享一个压箱底的小技巧。量产产品的看门狗超时时间不要设得太理想化，要考虑到极端情况：Flash擦写时的干扰、EEPROM写入卡顿、外部传感器偶尔无响应等。我会在产品做完环境试验后，把喂狗日志记录下来，统计分析平均喂狗时间和最大喂狗间隔，如果最大间隔已经逼近看门狗超时时间了，就该考虑加大超时时间或者优化业务代码的执行效率。看门狗是系统的最后一道防线，它不应该成为业务代码执行效率的惩罚者。
