MCU 看门狗复位莫名其妙？喂狗时序与窗口看门狗实战

板子跑着跑着自己复位，查 log 是看门狗复位，但代码里明明喂了狗。这种"灵异复位"一般是这几个原因：

1. 喂狗放在中断里，主循环卡死照样喂
最常见的错误：把喂狗写在 SysTick 中断里，主循环死锁了中断还在跑，狗永远饿不死。喂狗必须放在主循环的关键路径上，或者喂狗前检查任务心跳。

2. 喂狗间隔抖动太大
独立看门狗超时时间是固定的，如果主循环某次执行时间波动大（比如偶发的大数据量处理），就会偶发复位。实测主循环最坏执行时间，超时时间留 2 倍以上余量。

3. 上电/低功耗模式没处理好
从 Standby 唤醒后看门狗状态、时钟源可能变了，唤醒流程里要重新初始化看门狗。独立看门狗一旦使能就停不下来，进低功耗前要算好账。

4. 窗口看门狗喂早了也复位
窗口看门狗不光不能晚喂，还不能喂太早。喂狗时机必须落在窗口期内，中断里随手喂狗反而会触发复位。用窗口看门狗的场景，喂狗点要精心设计，别图省事。

5. 复位原因要记录
复位后第一时间读复位标志寄存器，区分是上电复位、软件复位还是看门狗复位，存到 Flash 里。没有复位原因记录，查灵异复位就是盲人摸象。

你们项目里看门狗一般配多长的超时？欢迎交流。

Thanks for sharing, very thorough. We learned this lesson the hard way too.

「hard way」这个词太有共鸣了，补充几个我们交过学费才长记性的点：第一，复位后第一时间读 RCC 复位标志并存到 Flash，没有复位原因日志，查灵异复位就是盲人摸象，现场复现不了等于白查；第二，窗口看门狗最容易栽在「喂早了」——有人在中断里顺手喂狗，结果触发窗口违例反而复位，喂狗时机必须落在窗口期内，喂狗点要精心设计；第三，低功耗唤醒后独立看门狗的时钟源可能变了，超时时间跟着变，Standby 唤醒流程里必须重新初始化看门狗；第四，喂狗间隔按最坏主循环执行时间留 2 倍以上余量，偶发的大数据量处理那次就是这么栽的。复位原因日志+喂狗前检查任务心跳这两招落地后，灵异复位基本绝迹。你们那次 hard way 是栽在哪一条上？