嵌入式看门狗原理与实战：硬件WDT配置、喂狗策略与复位机制-平芜编程栈

1. 看门狗不是“宠物”，是嵌入式系统里最沉默的守夜人

“看门狗”这个词一出来，很多人第一反应是蹲在门口摇尾巴的土狗——但嵌入式工程师听到这三个字，后颈汗毛会本能地竖起来。它不咬人，不叫唤，甚至不露面，可一旦它“醒来”，整台设备就直接硬重启，所有运行中的状态、缓存数据、通信连接全归零。这不是故障，是设计；不是意外，是救赎。看门狗（Watchdog Timer, WDT），本质上是一块独立于主MCU逻辑之外的硬件计时器，它的唯一使命就是：定期确认“系统还活着”。你得按时“喂狗”——也就是在它倒计时归零前，向它写入一个特定值（通常叫“喂狗指令”或“清零操作”）；如果你忘了、卡死了、跑飞了、陷入死循环了，它就毫不留情地拉下复位引脚，强制系统从头开始。

我做过十几个工业控制板项目，最深的体会是：看门狗从来不是为“正常运行”而设，而是为“不可预知的异常”兜底。它不关心你的PID算法调得多准、ADC采样多稳定、CAN总线通信多流畅——它只认一个事实：你有没有在规定时间窗口内，老老实实来打个卡。这个“打卡时间”，短则几毫秒，长则数秒，取决于你的系统响应要求和容错裕度。比如一台电机驱动器，如果主控在FOC计算中因浮点溢出锁死，看门狗会在200ms内触发复位，避免功率器件持续导通烧毁；而一台智能电表，可能允许5秒超时，因为要兼顾计量精度与低功耗唤醒周期。

它和“复位电路”不是一回事，但又密不可分。复位电路（比如RC延时或专用复位芯片如MAX706）负责上电那一刻的初始清零，确保MCU从确定状态启动；而看门狗是在系统运行起来之后，持续监控其“健康状态”的第二道防线。两者配合，才构成完整的“生-存-死-生”闭环。你查RK3506、STM32H7、鼎微T3这些芯片手册，翻到“Reset and Clock Control”章节，WDT永远和POR（Power-On Reset）、BOR（Brown-Out Reset）、NRST引脚并列出现——它不是附加功能，是芯片级基础设施。别被“喂狗”这种轻松叫法骗了，这活儿干得不好，轻则设备频繁重启丢数据，重则现场设备失控酿成事故。下面我们就一层层剥开它的皮，看看骨头怎么长、血怎么流、怎么让它真正为你站岗。

2. 看门狗的底层逻辑：一个独立计时器如何接管生死大权

2.1 硬件结构：为什么必须“独立”？

看门狗的核心价值，源于它物理隔离于主CPU系统之外。这不是软件循环计数器，也不是靠SysTick中断模拟的“伪看门狗”。真正的硬件WDT，由三部分硬核组成：

独立振荡源：通常是一个精度不高（±30%）、功耗极低的RC振荡器（如STM32的LSI，32kHz），或者外接一个廉价陶瓷谐振器。它不依赖主晶振（HSE），哪怕主时钟因干扰停振，WDT照样滴答走。
递减计数器：一个固定位宽（常见8位、12位、16位）的寄存器，上电或复位后加载预设初值，然后持续递减。当它减到0x00时，立即触发复位信号。
喂狗锁存器/窗口机制：这是防误触发的关键。简单型WDT只要求你在超时前任意时刻喂一次；而高级型（如STM32的IWDG/WWDG）引入“窗口期”——你只能在计数器值降到某个阈值（如0x40）之后、归零之前这个狭窄窗口内喂狗。早喂（值还很大）或晚喂（已过窗口）都会被视为异常，直接复位。这杜绝了程序在死循环里盲目刷喂狗指令的漏洞。

提示：为什么不用主CPU时钟？因为主时钟一旦被干扰（如EMI噪声导致PLL失锁）、或程序错误修改了时钟配置寄存器，整个系统时序就乱套了。此时若WDT也跟着挂掉，等于守夜人和主人一起睡死过去。独立振荡源，就是那个永远醒着的哨兵。

2.2 复位路径：从计数器归零到芯片重启的0.5ms全过程

当WDT计数器归零，它不会温柔地发个中断提醒你“该醒了”。它直接、粗暴、不可逆地驱动NRST引脚（或内部复位信号线）。这个过程在芯片内部是硬连线的，绕过所有软件逻辑：

信号生成：WDT模块内部产生一个高电平复位脉冲（典型宽度1.2ms，具体查芯片手册“Reset Timing”表格）；
复位传播：该脉冲送入芯片的复位控制器（RCC），同时拉低所有外设时钟使能位、清空所有寄存器、将PC指针强制指向0x00000000（或向量表起始地址）；
电源与IO状态：复位期间，所有GPIO保持高阻态（或按复位默认状态），SRAM内容丢失（除非有备份域供电），Flash读取暂停；
启动执行：复位脉冲结束后，CPU从复位向量取指，执行启动代码（startup_xxx.s），初始化堆栈、拷贝data段、清零bss段，最终跳转到main()。

这个过程完全硬件化，耗时极短（通常<2ms），且不受任何软件干预。你无法在复位过程中插入调试代码，也无法用SWD/JTAG暂停它——这就是它的威慑力来源。这也是为什么“异步复位同步释放”成为关键设计原则：外部按键复位或电源跌落产生的复位信号，必须经过两级触发器同步到主时钟域，避免亚稳态导致复位信号抖动，造成MCU反复重启。而WDT复位本身就是同步设计的典范——它不依赖主时钟，却能精准控制主时钟域的生死。

2.3 “喂狗”的本质：不是礼貌问候，是生存认证

“喂狗”这个动作，在代码里往往只是一行IWDG->KR = 0xAAAA;（STM32）或WDTCTL = WDTPW | WDTCNTCL;（MSP430），看起来轻描淡写。但它的背后，是系统健康状态的实时认证：

时序约束：喂狗必须发生在超时窗口内。假设WDT超时时间为1.6s（以LSI=32kHz、12位计数器为例：2^12 / 32k ≈ 1.28s，再加预分频可调至1.6s），那么你的主循环或任务调度器，必须保证在任意连续1.6s内，至少执行一次喂狗。这意味着你的最长单次任务执行时间、最大中断关闭时间、最差情况下的RTOS调度延迟，都必须小于这个值。
位置敏感：不能只在main()开头喂一次。必须放在能反映系统全局活跃度的位置。最佳实践是：在RTOS的idle task中喂狗（如FreeRTOS的vApplicationIdleHook），或在主循环末尾（确保前面所有关键任务都已执行）。我曾遇到一个案例：某电机控制板在FOC计算中因浮点除零进入HardFault，中断服务程序没处理完就卡死，而喂狗指令恰巧在中断里——结果WDT永远等不到喂狗，3秒后复位。后来把喂狗移到主循环，问题解决。
防止单点失效：高级应用会采用“双看门狗”策略。例如，用MCU内置WDT监控主应用，再用一片独立WDT芯片（如MAX706）监控MCU的喂狗信号线。后者通过检测MCU GPIO的周期性翻转来判断主MCU是否存活，形成双重保险。这在医疗设备、汽车ECU中是强制要求。

3. 实战配置全解析：从STM32CubeMX到裸机寄存器操作

3.1 STM32CubeMX图形化配置：三步锁定安全边界

STM32的WDT分为两类：IWDG（Independent Watchdog）和WWDG（Window Watchdog）。前者简单可靠，适合通用场景；后者带窗口机制，防止单点失效，适合高安全要求场合。我们以IWDG为例，演示CubeMX配置流程（基于STM32H743）：

启用IWDG：在“Pinout & Configuration”页，左侧栏选择“System Core” → “IWDG”，勾选“Enable”。此时右侧会显示配置面板。
设置预分频与重装载值：
- Prescaler（预分频）：提供4档选择（4/8/16/32）。它把LSI时钟（≈32kHz）进一步分频。选4，则输入计数器的时钟为8kHz。
- Reload Value（重装载值）：12位寄存器，范围0x000~0xFFF（0~4095）。它决定计数器从多少开始倒计时。
- 计算超时时间：Timeout = (Reload_Value + 1) * (Prescaler) / LSI_Frequency。例如：LSI=32kHz，Prescaler=8，Reload=0xFFF（4095），则Timeout = (4095+1) * 8 / 32000 = 1.024s。CubeMX右下角会实时显示计算结果，务必确认它符合你的系统需求。

生成代码与初始化：点击“Generate Code”，CubeMX会自动生成MX_IWDG_Init()函数。关键点在于：

void MX_IWDG_Init(void) { LL_IWDG_EnableWriteAccess(IWDG); // 允许写入寄存器（WDT寄存器默认写保护） LL_IWDG_SetPrescaler(IWDG, LL_IWDG_PRESCALER_8); // 设置预分频 LL_IWDG_SetReloadCounter(IWDG, 4095); // 设置重装载值 LL_IWDG_Enable(IWDG); // 启动WDT！此步后计数器开始倒计时 }

注意：LL_IWDG_Enable()必须在所有寄存器配置完成后执行，否则未配置的WDT会以默认值（通常很短）运行，导致立即复位。

3.2 裸机寄存器操作：理解每一比特的意义

脱离HAL库，直操作寄存器，能看清WDT的骨骼。以STM32F103为例（寄存器映射更经典）：

键寄存器（IWDG_KR）：地址0x40003000。写入0xCCCC启动WDT（此时计数器开始运行）；写入0xAAAA喂狗；写入0x5555解锁寄存器写入权限（用于修改预分频和重装载值）；写入0x0000禁止WDT（仅在解锁后有效）。
预分频/重装载寄存器（IWDG_PR & IWDG_RLR）：地址0x40003004/0x40003008。PR的低3位（bit0-2）控制预分频系数（000=4, 001=8,..., 111=256）；RLR是12位重装载值。
状态寄存器（IWDG_SR）：地址0x4000300C。bit0（PVU）表示预分频更新忙，bit1（RVU）表示重装载值更新忙。在修改PR或RLR后，需轮询对应位清零，确认写入完成。

一段可靠的裸机喂狗代码：

// 初始化WDT：超时约1.2s void IWDG_Init(void) { RCC->APB1ENR |= RCC_APB1ENR_IWDGEN; // 使能IWDG时钟（F1系列需此步） IWDG->KR = 0x5555; // 解锁寄存器 IWDG->PR = 0x00; // 预分频=4 IWDG->RLR = 0xFFF; // 重装载=4095 while(IWDG->SR & 0x0001); // 等待PVU清零 while(IWDG->SR & 0x0002); // 等待RVU清零 IWDG->KR = 0xCCCC; // 启动WDT } // 喂狗：必须在超时前调用 void IWDG_Feed(void) { IWDG->KR = 0xAAAA; // 写入喂狗键 }

实操心得：很多新手在CubeMX里配好WDT，却忘记在main()里调用MX_IWDG_Init()，或者调用顺序错了（比如在HAL_Init()之前调用，导致时钟未初始化）。还有人把喂狗放在中断里，结果中断被屏蔽时WDT超时——记住，喂狗位置必须是系统全局活跃度的可靠指示点。

3.3 RK3506等国产SoC的特殊考量：WDT不止一个

RK3506这类ARM Cortex-A系列SoC，WDT架构更复杂。它通常集成多个WDT通道，服务于不同子系统：

WDT0：专用于ARM CPU子系统，复位整个AP（Application Processor）域；
WDT1：服务于GPU或VPU（视频处理单元），防止图形渲染卡死；
WDT2：监控DDR控制器，避免内存访问异常导致系统僵死；
PMIC WDT：通过I2C连接电源管理芯片（如RK806），实现“电源级复位”。

配置方式不再是简单的寄存器写入，而是通过Linux内核驱动或U-Boot命令。例如在U-Boot下：

# 查看WDT状态 => wdt status # 启动WDT0，超时10秒 => wdt start 0 10000 # 手动喂狗 => wdt reset 0

而在Linux用户空间，可通过/dev/watchdog设备文件操作：

# 加载WDT驱动 modprobe rk3399_wdt # 启动并喂狗（需root权限） echo 0 > /dev/watchdog # 启动 echo V > /dev/watchdog # 喂狗（'V'是喂狗magic byte）

注意：RK3506的WDT默认可能处于禁用状态，且需要正确配置CLK和RESET控制器。若刷机后WDT失效（如S905X复位键不起作用），大概率是U-Boot阶段未正确初始化WDT寄存器，或固件中遗漏了wdt_start()调用。这需要深入分析U-Boot源码中的board_init_f()流程。

4. 看门狗的陷阱与避坑指南：那些让工程师彻夜难眠的细节

4.1 “喂狗”位置错误：最隐蔽的死循环诱因

喂狗位置选错，是导致WDT误触发的头号原因。常见错误模式：

放在中断服务程序（ISR）里：看似合理，但若主程序因优先级设置错误，长时间关闭全局中断（__disable_irq()），或某个高优先级中断持续抢占，导致喂狗ISR无法执行，WDT就会超时。我曾调试一台PLC，发现它每15分钟规律性重启，最后定位到一个CAN接收中断里做了长达8ms的浮点运算，而喂狗恰好放在此中断里——当CAN流量激增时，喂狗被饿死。
放在条件分支里：如if (system_state == RUNNING) IWDG_Feed();。一旦system_state因变量未初始化、内存越界被篡改，变成非RUNNING状态，喂狗就永久停止。
放在RTOS任务里，但任务被挂起：比如一个喂狗任务设置了较高优先级，但被更高优先级的通信任务长期抢占，或因等待信号量超时而阻塞。

正确做法：喂狗应置于系统最底层、最高优先级、无条件执行的代码路径中。推荐方案：

在裸机系统中：主循环while(1)的末尾；
在FreeRTOS中：vApplicationIdleHook()钩子函数（idle task永不阻塞）；
在RT-Thread中：rt_thread_idle_entry()函数内；
在裸机+中断系统中：在SysTick中断里喂狗（SysTick频率稳定，且几乎不被屏蔽）。

4.2 时钟源漂移：温漂与电压波动带来的隐形杀手

WDT依赖的LSI（Low Speed Internal）RC振荡器，精度极差（典型-40%~+50%），且受温度和VDD影响显著。一块STM32F4在-40°C时LSI可能只有20kHz，而在85°C时飙升至45kHz。这意味着你精心计算的1.6s超时，在低温下可能缩至1.0s，在高温下拉长到2.2s。

后果：在低温环境下，系统可能因WDT超时过快而频繁重启；在高温下，WDT响应变慢，对真实故障的拦截能力下降。

解决方案：

冗余设计：在CubeMX中，将Reload值设为理论值的70%（如理论1.6s，实际设1.1s），留出30%裕度应对温漂；
校准补偿：高端应用中，可在出厂时用高精度时钟源（如TCXO）校准LSI，并将校准系数存入Flash，在启动时动态调整Reload值；
选用高精度WDT芯片：如MAX6369，内置温度补偿晶体振荡器，精度达±0.5%，但成本增加。

4.3 复位后状态丢失：如何让系统“记得自己是谁”

WDT复位后，MCU所有寄存器、RAM内容清零，但有些信息必须保留，否则重启等于“失忆”。典型需求：

记录复位原因：区分是WDT复位、上电复位、还是手动复位，便于故障诊断；
保存关键参数：如电机当前转速、电池剩余电量、网络连接状态；
避免重复初始化：如Flash擦写、EEPROM校验等耗时操作，不应每次重启都执行。

实现方法：

使用备份寄存器（Backup Registers）：STM32等MCU提供4-32个32位备份寄存器（BKP_DRx），由VBAT供电，WDT复位不丢失。启动时读取BKP_DR1，若值为0xA5A5，则说明是WDT复位，可执行特定恢复逻辑。
利用RTC备份域：将关键数据存入RTC的备份RAM（如STM32的RTC_BKPxR），同样由VBAT维持。
软件标记：在SRAM中定义一个“Magic Flag”区域（如uint32_t __attribute__((section(".backup_ram"))) reset_flag;），并在启动代码中检查其值。但需注意：普通SRAM在复位后内容随机，必须配合__init_data或__no_init属性确保编译器不自动清零。

实操心得：我在做一款智能锁项目时，曾因忽略复位原因识别，导致用户抱怨“锁经常自己开”。后来加入备份寄存器记录，发现90%的WDT复位源于指纹传感器SPI通信超时。于是优化了SPI超时处理，并在WDT复位后自动重试指纹识别，用户体验大幅提升。

4.4 WDT与低功耗的生死博弈：休眠时如何“假死真活”

在电池供电设备（如无线传感器节点）中，MCU大部分时间处于Stop或Standby模式，此时主时钟关闭，但WDT必须继续工作，否则无法唤醒。矛盾点在于：WDT依赖的LSI在Stop模式下仍运行，但其精度和功耗需重新评估。

典型陷阱：

Stop模式下LSI不稳定：某些MCU在Stop模式下LSI会暂时停振，待唤醒后才恢复，导致WDT计时不准；
WDT超时唤醒冲突：WDT超时本应复位，但在Stop模式下，它可能被配置为产生中断而非复位，导致唤醒后程序继续执行，而非重启。

安全配置：

明确WDT行为：在进入Stop前，确认WDT配置为“复位模式”（而非中断模式）。STM32的IWDG只有复位一种行为，WWDG才有中断选项；
缩短超时时间：低功耗场景下，WDT超时不宜过长（如设为2s），避免电池在休眠中被异常耗尽；
唤醒后自检：从Stop唤醒后，立即执行RAM校验、外设状态检查，若发现异常，主动触发软件复位，比等待WDT更可控。

5. 高级应用场景与扩展：从单片机到SoC的全链路守护

5.1 双看门狗架构：给安全关键系统上双保险

在汽车电子（ASIL-B/C）、医疗设备（IEC 62304）中，单一WDT不满足功能安全要求。必须采用硬件级冗余看门狗：

主WDT：MCU内置IWDG，监控主应用软件；
辅WDT：独立WDT芯片（如MAX706、TPS3823），其输入端连接MCU的一个GPIO（如PA0），该GPIO由主应用周期性翻转（如1Hz方波）；
逻辑关系：辅WDT芯片监测PA0的翻转频率。若频率低于阈值（如<0.8Hz），即判定MCU异常，立即拉低其RESET输出，复位整个系统。

这种架构的优势在于：即使MCU固件被恶意篡改（如植入后门），只要它无法维持GPIO翻转，辅WDT就会介入。而辅WDT芯片本身无软件，无法被攻击，真正实现了“硬件可信根”。

电路设计要点：

PA0需加10kΩ上拉电阻，确保MCU复位时PA0为高电平，避免辅WDT误判；
辅WDT的RESET输出需与MCU的NRST引脚直接相连，并加0.1μF去耦电容；
供电必须独立：辅WDT由LDO单独供电，避免主电源噪声影响其稳定性。

5.2 WDT在Bootloader中的角色：防止“砖化”的最后一道墙

OTA升级失败是嵌入式设备“变砖”的主因。一个健壮的Bootloader必须集成WDT保护：

升级过程监控：Bootloader在擦写Flash、校验固件、跳转新程序等关键步骤，均开启WDT并设置较短超时（如500ms）。若某步卡死（如Flash写入失败），WDT强制复位，回退到旧固件；
双Bank机制：将Flash分为Bank A（当前运行）和Bank B（待升级）。升级时先写入Bank B，校验通过后再更新跳转指针。WDT全程监控Bank B写入过程；
看门狗喂狗策略：在Bootloader中，喂狗必须与实际进度绑定。例如，每成功写入一页Flash（256B），才喂一次狗。避免在死循环中盲目喂狗。

案例：某客户使用鼎微T3 MCU开发智能电表，早期版本Bootloader无WDT保护，一次电网瞬时干扰导致Flash擦除中断，设备永久无法启动。加入WDT后，干扰发生时WDT超时复位，Bootloader检测到Bank B无效，自动回退到Bank A，设备恢复正常。

5.3 SoC级WDT协同：RK3506与PMIC的生死握手

在RK3506这类复杂SoC中，WDT不仅是CPU的守卫，更是整个电源域的协调者。其与PMIC（电源管理芯片）的协同至关重要：

PMIC WDT功能：RK806等PMIC内置WDT，可通过I2C配置。它监控SoC发送的“心跳包”，若SoC在设定时间内未发送（如通过I2C写入特定寄存器），PMIC将切断主电源（VDD_CPU、VDD_GPU），实现硬断电。
协同流程：
1. SoC启动后，初始化PMIC，配置其WDT超时时间（如30s）；
2. SoC的Linux内核WDT驱动，定期向PMIC的WDT寄存器写入“喂狗”值；
3. 若SoC因内核崩溃、死锁无法喂狗，PMIC WDT超时，强制关断所有电源轨；
4. 用户长按电源键，PMIC检测到按键信号，重新上电启动。

这种“SoC WDT + PMIC WDT”两级机制，解决了单纯SoC WDT无法应对电源管理固件死锁的问题。例如，当RK3506的PMIC固件因I2C通信异常卡死，SoC WDT可能无法复位PMIC，但PMIC自身的WDT会检测到自身异常，执行安全关断。

调试要点：若遇到“RK3506开机黑屏”，需用逻辑分析仪抓取I2C总线，确认SoC是否在启动初期向PMIC WDT寄存器写入了正确值。很多固件问题，根源在于U-Boot阶段未正确初始化PMIC WDT。

6. 常见问题速查表与终极排查心法

问题现象	可能原因	排查步骤	解决方案
设备规律性重启（如每2秒一次）	WDT超时时间设置过短；喂狗代码未执行	1. 检查CubeMX中Reload/Prescaler计算值； 2. 在喂狗位置加LED闪烁或串口打印，确认是否执行； 3. 用示波器测NRST引脚，确认复位脉冲宽度	将Reload值增大30%；确认喂狗位于主循环末尾或idle hook
WDT复位后，系统行为异常（如参数错乱）	复位原因未识别；备份寄存器未初始化	1. 检查启动代码中是否读取BKP_DRx； 2. 用调试器查看SRAM中关键变量值是否被清零	在`SystemInit()`后立即初始化备份寄存器；在main()开头添加复位原因判断逻辑
低功耗模式下WDT不工作	Stop模式下LSI被关闭；WDT未使能	1. 查阅芯片手册“Low Power Modes”章节； 2. 确认`PWR_CR`寄存器中`LPDS`位设置； 3. 检查WDT初始化代码是否在进入Stop前执行	在进入Stop前调用`LL_IWDG_Enable()`；确认LSI在Stop模式下保持使能
RK3506刷机后WDT失效	U-Boot未初始化WDT；内核驱动未加载	1. 在U-Boot命令行执行`wdt status`； 2. 检查U-Boot源码`board/rockchip/rk3506/rk3506.c`中是否有`wdt_init()`调用； 3. Linux下执行`ls /dev/watchdog`	修改U-Boot，在`board_init_f()`中添加`wdt_init()`；在内核配置中启用`CONFIG_ROCKCHIP_WDT`
喂狗后WDT仍超时	寄存器写保护未解除；喂狗键值错误	1. 检查`IWDG_KR`写入顺序（先0x5555，再0xAAAA）； 2. 用调试器观察`IWDG_SR`寄存器PVU/RVU位是否为0； 3. 确认`IWDG_KR`地址是否正确（F1为0x40003000，H7为0x58004800）	严格按手册时序写入；使用`LL_IWDG_EnableWriteAccess()`替代手动写0x5555

终极排查心法——三步定位法：

确认复位源：这是起点。所有MCU都有复位原因寄存器（如STM32的RCC_CSR中IWDGRSTF位）。在main()开头立即读取并打印，确认是否真是WDT复位，而非POR、BOR或手动复位。很多“WDT问题”其实是电源不稳导致的POR。
隔离喂狗路径：在喂狗位置添加最简验证——点亮一个LED。如果LED不闪，说明喂狗代码根本没执行，问题在流程控制（如条件分支、任务挂起）；如果LED常亮，说明喂狗执行了，但WDT仍超时，问题在时序（超时设置过短、LSI漂移）或硬件（NRST引脚被意外拉低）。
时间域分析：用示波器抓NRST和喂狗GPIO（如PA0）波形。测量两次喂狗间隔、喂狗到NRST下降沿的时间。若间隔恒定且小于WDT超时值，说明WDT本身没问题，问题在喂狗之前的代码卡死；若间隔远大于超时值，说明喂狗路径被阻断。

我踩过的最大坑，是在一个STM32H7项目中，WDT配置完全正确，喂狗也执行，但设备仍每3秒重启。最后发现是HAL_RCC_OscConfig()里启用了HSI48作为USB时钟源，而HSI48的校准值被意外写坏，导致系统时钟树紊乱，SysTick中断频率异常，进而影响了喂狗时机判断。这提醒我们：WDT不是孤立模块，它是整个时钟、电源、复位系统的神经末梢，排查必须全局视角。

最后分享一个小技巧：在量产测试中，我会在产线烧录固件时，故意注释掉一行喂狗代码，然后让设备运行24小时。如果它没重启，说明WDT根本没起作用——要么配置错误，要么硬件WDT被禁用（某些MCU出厂默认关闭WDT）。这个“反向压力测试”，比任何仿真都可靠。看门狗的价值，不在它天天工作，而在它沉默时，你依然相信它随时能拔刀。