扫码关注
一直在喂狗，系统为何仍可能假死？
喂狗动作只能证明某段代码被执行，不能自动证明所有任务、外设和通信链路都健康
若喂狗放在定时中断、空闲任务或一个仍能运行的主循环分支里，即使关键任务死锁、外设卡住或数据停止更新，看门狗仍会持续刷新。可靠方案要把喂狗权限绑定到多个健康条件，并根据失效模式选择独立或窗口看门狗。
系统界面不更新、通信不再响应，电源和时钟都还在，日志停在故障前一行；可看门狗始终没有复位。调试时一查，喂狗函数确实每隔几百毫秒执行。这里的关键判断是：喂狗成功只证明喂狗代码活着，不等于整个系统健康。
看门狗本质上只认识倒计时器。只要刷新动作赶在超时前发生，它就判断软件正常；若刷新点没有绑定关键任务、数据和外设的前进条件，业务已经假死，计数器仍会被一个无关路径清零。
喂狗点放错，死锁也能被掩盖
把喂狗放在固定周期中断里最省事，但只要中断还能响应，它就会继续执行；主循环或某个任务即使卡死，也未必触发复位。放在RTOS空闲任务同样有盲区：高优先级任务异常占满CPU时会触发，但低优先级关键任务饿死时，空闲任务未必能反映它。
图1 窗口看门狗允许刷新与禁止刷新区间
更可靠的思路是让每个关键任务在完成一次有效工作后上报健康标志，由监护逻辑检查所有标志、数据是否更新、外设是否前进，再决定是否喂狗。喂狗应是健康检查的结果，不是定时动作。
独立看门狗能覆盖什么？
独立看门狗使用独立于主系统时钟的低速振荡器。主时钟停止或CPU执行流失控时，它仍可继续倒计时并产生复位，这比依赖同一主时钟的普通定时器更适合承担兜底恢复。
图2 独立看门狗的LSI、预分频与递减计数结构
但“独立”不等于万能。如果负责刷新它的中断仍在运行，或者故障只让业务数据停滞而CPU继续跑，独立看门狗同样可能被喂住。它解决的是计时来源独立，不是健康判断自动正确。
独立低速振荡器通常有较大频率公差，超时时间要按最慢和最快边界计算。只用标称频率设置两秒，实际复位点可能明显偏离；正常最坏执行时间和故障恢复时间都要留余量。
时钟独立提高了覆盖面，却没有替你定义“系统健康”。
窗口看门狗为什么还能抓“喂太快”？
普通看门狗只检查是否超时，代码若跑飞到一个高频喂狗循环，反而永远不会复位。窗口看门狗增加了允许刷新区间：太早刷新和太晚刷新都视为异常。
图3 窗口看门狗的递减计数器与比较逻辑
这让它能识别执行节拍明显变快或变慢的故障，但窗口参数必须覆盖正常调度抖动、中断延迟和最差负载。窗口过窄会造成误复位，过宽又失去诊断价值。
窗口看门狗适合检查节拍，但RTOS调度抖动、Flash擦写和长中断会让合法刷新时间变化。窗口应根据实测最坏延迟设定，不能只用平均周期，否则现场偶发误复位会很难解释。
· 独立看门狗：重点覆盖超时与主时钟异常。
· 窗口看门狗：同时限制刷新过早和过晚。
· 健康聚合：决定什么时候允许执行刷新。
怎样做一次真正的故障注入？不要只在主循环里写while(1)测试。分别注入任务死锁、通信状态机不前进、传感器数据冻结、中断风暴和喂狗循环跑飞，记录每种故障是否被健康逻辑阻止喂狗，以及复位后能否保存原因。
同时检查调试模式、低功耗模式和启动阶段的边界。某些器件允许调试暂停看门狗，某些看门狗启用后不能软件关闭。超时时间应覆盖合法最坏执行时间，并保留足够诊断日志写入窗口。
图4 独立看门狗寄存器组与状态检查
1. 列失效模式明确要发现的是哪类假死。
2. 绑定健康标志关键任务完成工作后才上报。
3. 逐项注入确认每种故障都能停止喂狗并留痕。
健康标志要证明工作前进健康标志不能只表示“任务获得过CPU”。更有意义的条件是队列被消费、序号前进、传感器时间戳更新或通信状态机完成一轮；否则任务在错误循环里打转，也可能持续报到。
复位后还要防止启动循环复位之后还要避免启动循环。若同一外设故障让系统每次启动后立即再次超时，应记录复位原因、失败计数和安全降级状态，必要时停止反复拉起高风险负载。
结论一直在喂狗，系统仍可能假死，是因为“刷新动作”与“业务健康”被错误地画上了等号。看门狗不会理解任务、数据和外设，它只会判断计数器有没有被重装。
把喂狗权限收敛到一个健康聚合点，再用独立或窗口机制覆盖不同时间异常，并通过故障注入证明。这样看门狗才从一个定时器变成可靠性设计。
你的喂狗函数现在放在定时中断、主循环，还是独立监护任务里？
