2. 看门狗基本工作原理
看门狗(Watchdog)本质上是一个“独立于主程序运行、对主程序是否按时报到进行监督”的定时器。它的核心思想非常朴素:如果被监督的程序在规定时间内没有给出“我还活着”的信号,看门狗就认为系统已经跑飞或卡死,于是主动产生复位,把系统拉回一个已知的初始状态。理解看门狗,关键要抓住三件事:定时器如何计数、喂狗信号如何被接受、超时后复位如何被触发。
一、定时器喂狗机制
看门狗内部通常有一个递减或递增的计数器,由独立时钟源驱动。以常见的递减计数器为例,上电后计数器被装入一个初值(重装载值),随后每个时钟周期减 1。当计数值减到 0 时,看门狗溢出,触发复位。所谓“喂狗”,就是在计数器减到 0 之前,通过写寄存器或翻转指定引脚的方式,把计数器重新装回初值,让它重新开始计数。
设看门狗时钟频率为 fwd,预分频系数为 P,重装载值为 R,则超时时间 Tto 近似为:
T_to = (P × R) / f_wd
示例(假设值):
f_wd = 32 kHz,P = 64,R = 1000
T_to = (64 × 1000) / 32000 = 2.0 s
这意味着主程序必须在 2 秒内至少喂狗一次。喂狗动作本身很简单,但“在哪里喂、由谁喂、喂多快”才是工程上的难点。如果只在主循环末尾喂狗,而某个子任务阻塞了主循环,看门狗就会误判;如果喂狗频率过高,又可能掩盖真正的卡死。因此,喂狗点通常放在能够证明“关键任务链完整执行”的位置,而不是随便找一个循环。
二、超时复位逻辑
超时复位是看门狗最直接的动作。计数器溢出后,看门狗模块会向复位控制器发出复位请求,复位控制器再拉低系统复位线,使 CPU、外设和部分寄存器回到初始状态。复位后,系统重新启动,看门狗通常也会被重新初始化。这里有一个重要细节:复位并不等于故障被修复,它只是把系统从“不可控状态”拉回“可控状态”。如果故障是持续性的,系统可能反复复位,形成“复位—启动—再复位”的循环。因此,实际系统中常配合复位原因寄存器,记录本次复位是否由看门狗触发,便于事后分析。
三、窗口看门狗与普通看门狗差异
普通看门狗只要求“不要超时”,即喂狗太晚不行,但喂狗太早没关系。窗口看门狗则增加了一个“窗口”概念:喂狗必须落在允许的时间窗口内,太早或太晚都会触发复位。这样做的目的是防止程序跑飞后恰好在一个固定位置快速喂狗,从而掩盖故障。窗口看门狗更适合对时序完整性要求高的场景,例如航空航天电子中的控制律计算、总线通信周期任务等。
下面这张图对比了普通看门狗与窗口看门狗在喂狗时间上的判定关系。图中横轴表示时间,纵轴表示计数器状态,绿色区间表示允许喂狗,红色区间表示禁止喂狗或已超时。
从图中可以看出,普通看门狗只有一个“截止时间”,窗口看门狗则有两个边界:下限和上限。窗口看门狗对喂狗时序的约束更强,因此对程序执行路径的完整性验证也更强。在航空航天电子中,如果某个周期任务必须在固定时间窗内完成,窗口看门狗可以同时检测“任务是否执行”和“任务是否在正确的时间执行”。
四、硬件看门狗与软件看门狗的边界
硬件看门狗是独立于 CPU 的物理模块,通常集成在 MCU 内部或作为外部芯片存在。它有自己的时钟源和计数器,即使 CPU 时钟停止、程序跑飞,硬件看门狗仍能继续计数并触发复位。软件看门狗则是利用系统定时器中断或任务调度器实现的“软监督”,它依赖 CPU 和操作系统正常运行。如果 CPU 被高优先级中断长期占用,或者调度器本身失效,软件看门狗也可能失效。
两者的边界可以这样理解:硬件看门狗解决“CPU 是否还在跑”的问题,软件看门狗解决“任务是否按预期执行”的问题。实际系统中,二者常常配合使用:硬件看门狗负责兜底,软件看门狗负责细粒度的任务监督。例如,在航空航天电子中,可以用硬件看门狗监督整个飞控计算机,用软件看门狗监督各个周期任务;当某个任务超时,先由软件看门狗记录故障并尝试恢复,若恢复失败,再由硬件看门狗触发整机复位。
| 对比维度 | 硬件看门狗 | 软件看门狗 |
|---|---|---|
| 实现载体 | 独立定时器模块或外部芯片 | 系统定时器中断或任务调度器 |
| 时钟依赖 | 独立时钟源,不依赖 CPU 时钟 | 依赖 CPU 时钟和操作系统 |
| 监督粒度 | 整机级,粗粒度 | 任务级,细粒度 |
| 典型动作 | 直接触发系统复位 | 记录故障、任务重启、降级运行 |
| 失效风险 | 时钟源故障、复位线故障 | 调度器失效、中断被屏蔽 |
五、工程实现中的关键判断
在实际工程中,看门狗的参数配置和喂狗策略需要结合任务周期来确定。假设某飞控任务周期为 10 ms,最坏执行时间为 6 ms,那么看门狗超时时间不能小于 10 ms,否则正常任务也会触发复位;但也不能太大,否则故障发现太晚。一个合理的示例是:取超时时间为任务周期的 3 倍,即 30 ms,同时要求主循环在每个周期内至少喂狗一次。如果某个周期任务超过 30 ms 仍未完成,看门狗复位,系统重新初始化。
此外,还要注意喂狗动作的“可信度”。如果喂狗只是简单写一个寄存器,那么程序跑飞后恰好执行到这条指令,也可能误喂狗。更可靠的做法是:喂狗前先检查关键状态变量是否处于预期值,或者使用“问答式”看门狗,即看门狗给出一个随机数,程序必须经过正确计算后返回答案,才能完成喂狗。这种方式可以显著提高看门狗对程序跑飞的识别能力。
总结来说,看门狗的基本工作原理可以归纳为:定时器计数、按时喂狗、超时复位。普通看门狗只约束“不要超时”,窗口看门狗同时约束“不要过早”;硬件看门狗提供独立兜底,软件看门狗提供任务级监督。理解这些边界,才能在航空航天电子系统中设计出既不过度敏感、也不轻易失效的故障恢复机制。