单片机看门狗为何误复位？喂狗窗口怎么定？

看门狗本该抓住死机，却常在现场变成莫名重启的来源。单片机系统如果没有把喂狗条件和最坏执行时间绑定，复位既可能误触发，也可能在真正卡死时失效。

误复位的第一类原因是任务阻塞路径被低估。主循环平时几十毫秒走完，一旦遇到 Flash 擦写、传感器超时、通信重连或等待锁，就可能超过看门狗周期。若喂狗点放在循环尾部，任何一个慢分支都会让系统看起来像死机；若喂狗点散在多个驱动里，某个底层函数即便上层任务已经失控，仍可能继续喂狗，把故障掩盖过去。最危险的是在中断里喂狗，因为主任务卡住时中断仍会运行，看门狗完全失去监控意义。

更稳妥的策略是集中喂狗，并让它依赖关键任务心跳。控制、通信、存储和安全监测各自按周期更新状态，只有所有必需任务都在期限内前进，监控任务才执行喂狗。对可能长时间运行的合法操作，要么拆成可让出的小段，要么在进入前显式切换到受控的长周期窗口，而不是让它偷偷越过预算。单片机固件资源有限，更需要把“系统仍健康”的条件写清楚，而不是把喂狗当成定时器回调。

窗口看门狗又引入另一条边界：太晚喂会复位，太早喂也会复位。它能发现程序跑飞后疯狂循环喂狗的情况，但前提是窗口要覆盖真实调度抖动。独立看门狗通常使用低速内部时钟，本身误差可能很大；低温、低压或不同批次都会改变实际超时时间。若窗口按典型值卡得太紧，现场温度一变，正常任务就可能被判为过早或过晚。启动阶段和低功耗唤醒阶段尤其容易出问题，因为任务尚未进入稳定节拍，却已经被窗口规则约束。

设窗口时要先做时间账。统计关键任务的最短正常循环、最长正常循环、合法阻塞上限和看门狗时钟最坏误差，再给窗口留出调度余量。启动、固件升级、深睡唤醒和故障自检可以使用独立状态机管理，不能混用运行态窗口。若系统进入低功耗后看门狗继续计时，要么保证唤醒周期小于下限，要么使用支持暂停或独立低功耗喂狗的机制。窗口下限也要防止异常快循环反复清狗，否则程序跑飞到空转路径时仍可能被误认为健康。单片机看门狗配置若只在室温空载下通过，现场误复位几乎不可避免。

排查时应在复位前保存最小故障现场，包括复位原因、最后一次成功心跳、当前任务号和关键锁状态。只知道发生了看门狗复位，无法判断是某个任务太慢、窗口太窄，还是时钟漂移。还应记录最近一次窗口内喂狗时间，避免把过早喂和过晚喂都归成同一类故障。通过故障注入让任务卡死、让通信超时、让 Flash 写入变慢，再观察看门狗是否按预期动作，才能证明它既不误杀，也不放过真故障。若故障现场写入非易失存储，还要确保它不会再次拉长复位前窗口。

因此，看门狗不是简单定期清零，而是一份健康判据。把喂狗资格交给任务进度，再按最坏时序设置窗口，复位才会指向真正异常。