一直在喂狗，MCU为何还是会复位？

一直在喂狗，MCU为何还是会复位？

窗口看门狗不只怕“喂得太晚”，也会拒绝“喂得太早”；函数一直在执行，时机仍可能不合法

日志里明明一直打印“喂狗”，MCU为什么还是会复位？如果用的是窗口看门狗，“喂过”并不等于“喂对了”。它要求刷新动作必须落在指定时间窗内。

程序卡死会导致喂狗过晚，错误的快循环或异常路径则可能不断提前刷新。窗口机制正是用来同时捕获这两类错误。

排查时要把寄存器计数值、实际时钟和复位原因串起来，不能只看一句打印。

窗口看门狗有两条边界

WWDG的递减计数器由PCLK1经预分频后驱动。计数值逐步下降，到达下限时会触发复位。

图1  WWDG通过Window比较器和下限同时限制刷新时机

另一条边界是Window阈值。当计数器还高于这个阈值时就刷新，会被认定为过早。

因此允许喂狗的区间在“已经低于上边界，但尚未达到下边界”之间。

窗口不宜设得过窄。样机在平均负载下看似稳定，实际中断突发、Flash擦写、总线超时和RTOS调度都会带来合法抖动，必须在窗口里留出余量。

计算窗口时可按寄存器计数的步进周期展开：先由PCLK1和预分频得到计数时钟，再算Counter从初值降到Window阈值需要多久，以及从阈值降到复位下限还剩多久。把允许范围换算成微秒或毫秒后，才方便与任务调度和中断时长比较。

刷新函数的返回值和寄存器写入条件也要检查。若HAL层因状态错误未真正写入，仅有上层调用日志仍会造成误判。

先用真实PCLK1计算时间

如果时钟树修改过，但WWDG参数还是按旧PCLK1计算，软件以为的窗口与硬件实际窗口就会错位。

图2  Counter、Window和预分频值只有结合PCLK1才能得到真实时间

预分频、Counter初值和Window值共同决定过早和过晚的时间边界。工具生成的参数也要核对时钟来源。

实时系统中还要把最坏中断占用、临界区和高优先级任务带来的抖动放入时间余量。

低功耗模式下要确认WWDG的时钟是否停止，以及唤醒后PCLK1是否切换。如果软件仍按进入低功耗前的节拍喂狗，可能在边界上失败。

早期唤醒中断发生在复位前的有限时间内，它更适合写入少量状态或设置故障标记，不适合执行格式化日志、Flash大块擦写或网络发送。处理时间过长不仅救不回系统，还可能让故障现场因新的阻塞而失真。

系统启动阶段常有时钟切换和耗时初始化。WWDG启用时点应明确，避免在任务调度尚未稳定前就进入正常运行窗口。

打印“喂狗”不代表刷新成功

日志通常在调用刷新函数之前或之后打印。它能证明代码路径进入，却未必能证明计数器当时处在合法窗口。

图3  日志只能说明程序路径，过早或过晚仍需要寄存器证据

复位后应第一时间读取并保存复位原因，然后清除标志。否则后续初始化可能把关键证据覆盖。

调试时可在刷新前读计数器值，并同时记录系统tick、任务状态和最近一次健康检查。

使用调试器单步时，CPU停下不代表WWDG一定停止。应根据器件调试冻结寄存器设置看门狗行为，否则断点本身就会制造复位。

健康位图要防止旧状态被重复使用。每个任务在本周期完成后置位，喂狗成功后立即清零，下一周期重新收集；否则某个任务只成功过一次，就可能永久被认为健康。跨中断或多任务访问时，还要保证位图更新的原子性。

多个任务共同决定健康状态时，要规定超时和依赖关系。一个非关键通信任务不应无条件阻止安全控制任务维持运行。

喂狗应该代表“系统健康”

如果在固定Delay之后无条件刷新，某个任务已经停止工作，喂狗任务仍可能按时运行，看门狗就失去了意义。

更稳妥的做法是让关键任务更新健康标志，只有所有必要模块都在本周期正常完成，才允许在窗口内刷新。

图4  窗口中断回调可记录状态，刷新仍应由健康条件决定

早期唤醒中断可用来保存最小故障现场，但处理必须短且确定，不要在其中执行长时间打印和阻塞操作。

上线版本应保留一个小型复位记录区，保存复位源、最近一次健康位图、喂狗计数值和关键错误码。这些信息比复位前来不及刷新的串口日志更可靠。

排查复位可建立一个小矩阵：空闲快循环关注过早刷新，高负载和长临界区关注过晚刷新，低功耗切换关注时钟变化，调试断点关注冻结设置。给每类场景预先定义要记录的寄存器和时间戳，复位后就不必只靠猜测。

复位记录区要有版本号和校验，防止固件升级后按旧结构解析。故障证据能稳定留下，看门狗才真正参与可诊断设计。

结论

一直在喂狗，却仍然复位，对窗口看门狗来说完全可能。它不只检查“有没有喂”，还检查“是不是在正确时间喂”。

用实际PCLK1重算窗口，刷新前记录计数值，复位后保存原因。这三个动作能快速分清过早、过晚和非WWDG复位。

声明：

本文由凡亿教育整理，转载请注明来源！

投稿/招聘/广告/课程合作/资源置换 请加微信：13237418207