看门狗 Watchdog

**中断中之所以清除中断标志位而没有将装载值赋值也没有复位，是因为这清除中断标志位是在喂狗（计数重新开始），所以没有触发复位，独立看门狗有没有配置中断使能，这个清除中断标志位就是喂狗操作。

工作中频繁碰到reset，一会听说是内狗reset了，又一会听说是外狗reset了。到底什么是看门狗，又到底什么是内狗，什么是外狗呢？接下来本文将你了解看门狗的基础知识和基础原理。

#01

什么是看门狗？

汽车控制器的看门狗与我们以前学习单片机所了解的看门狗其实是一个东西，即看门狗（Watchdog Timer，WDT）是一种特殊的定时器。它就像一个 “监督者”，用于监测微控制器系统的运行状态。当微控制器由于软件故障（如程序陷入死循环）、外部干扰（如电磁干扰导致程序跑飞）等原因不能正常运行时，看门狗会在设定的时间内没有被 “喂狗”（即没有执行复位操作）后，产生一个复位信号，使控制器重新启动，从而恢复系统的正常运行。

source: https://blog.csdn.net/zerothpower/article/details/108616557

看门狗通常有一个计数器，它会按照一定的时钟源进行递增或递减计数。在正常情况下，程序需要在看门狗计数器溢出（达到设定的时间限制）之前对其进行复位操作（喂狗），这样计数器就会重新开始计数，避免产生复位信号。如果程序因为故障无法在规定时间内喂狗，计数器溢出就会触发复位。

以TI TPS3851为例，它是一个带有集成看门狗计时器的监控器，这使得它既能监控微控制器的供电，又能以外部方式监控来自微控制器的数字脉冲。一种实现方式是通过微控制器的数字信号输出（GPIO）接入到外部看门狗计时器的看门狗输入（WDI），如下图所示：

Source: TI

微控制器定期向看门狗计时器发送脉冲，以表明系统软件运行正常。如果看门狗计时器在规定的时间范围内（称为看门狗超时）未接收到此脉冲，看门狗计时器就会断言一个复位输出。该复位输出可用于通知微控制器已出现卡顿或冻结，或用于复位微控制器本身。

下图描述了在看门狗超时内接收到的脉冲和在看门狗超时过后接收到的脉冲的两种情况：

Source: TI

#02

什么是硬件看门狗与软件看门狗？

看门狗通常分为硬件看门狗和软件看门狗，下面介绍下它们的主要类型及其工作原理。

2.1 硬件看门狗

常见的硬件看门狗有三种：独立看门狗、窗口看门狗和问答型看门狗。

1) 独立看门狗

独立看门狗通常使用一个独立的定时器，比如STM32的独立看门狗，其时钟源为内部的独立40kHz的RC振荡器，计数器位宽为12位。当正常运行时，主控制器需在计数器减到0之前通过喂狗操作重置计数器；若未及时喂狗，计数器计数到末尾则会产生复位信号，使系统复位。

独立看门狗独立于CPU之外，有自己的时钟源和计数器，可在系统低功耗模式下运行，硬件成本低，软件配置简单，可靠性高，适用于对硬件可靠性要求不是特别严格的场合。

2）窗口看门狗

窗口看门狗除了有递减计数器外，还有上下窗口值的设定，喂狗操作必须在设定的窗口时间内进行，即要求喂狗的时间点必须落在窗口期内，否则就会触发复位信号。

我们可以通过下图来做了解：

Source: https://www.allaboutcircuits.com/technical-articles/watchdog-timers

从A开始，启动后不久，软件使用计数器的上限初始化看门狗并启用计数。
在B 和 C ，软件在计数器达到上限之后成功为计数器提供服务，喂狗后，计数器重置为 0 并再次开始计数。
当达到D ，软件不为计数器提供服务，并且计数达到上限，看门狗重置微控制器。
从D 到 E，微控制器启动并初始化并启用看门狗。
从E开始，又开始计数，到F喂狗又重新开始计数。
当到G，程序在计数达到下限之前为计数器提供服务，到G就喂狗，被认为计数未达到下限，看门狗重置微控制器。

再比如英飞凌低压差稳压器TLE7273-2中的窗口看门狗，其每个看门狗窗口由一个打开的窗口和一个关闭的窗口组成，只有在打开的窗口期内接收服务才有效，否则报错。

总的来说，窗口看门狗对喂狗时间和系统运行逻辑有更严格的限制，能更精确地检测出系统异常，适用于时序要求严格的应用场景，比如工业控制等领域。

3）问答型看门狗

问答型看门狗要求微控制器按照要求执行一系列固定的对令牌值的算术运算，并将生成的令牌值返回给看门狗设备，设备验证微控制器是否在指定时间窗口内返回正确计算的响应，若不符合要求则视为异常事件，当异常事件计数达到预先定义的限制时，触发失败。

问答型看门狗必须每半个看门狗周期维护一次，这段时间由 WD_TIMER 和 WD_PRE 寄存器位配置的窗口时间定义。看门狗周期分为两个响应窗口，每个窗口占看门狗周期时间的一半。在第一个窗口期间，控制器 1 读取问题并发送前三个答案。然后控制器等待在第二个窗口中发送第四个也是最后一个答案，在第二个窗口结束时，一个新的看门狗周期开始，该过程重复进行，如下所示：

Source:

https://www.ti.com/lit/ug/slla546/slla546.pdf?ts=1747578322629&ref_url

问答型看门狗通过这种方式不仅监控微控制器是否在规定时间内响应，还对响应内容的正确性进行验证，进一步提高了系统可靠性，但同时也增加了控制软件的复杂度和硬件成本，常用于对功能安全等级要求较高的汽车系统，如驱动系统和制动系统等。

2.2软件看门狗

软件看门狗使用处理器的内部定时器来模拟实现定时器功能。在系统中，通过软件编程设定定时时间，在系统正常运行时，应用程序需在定时时间到达前进行喂狗操作，若未及时喂狗则触发相应的复位或处理机制。

比如采用外部看门狗监测单个CPU检测线程是否正常调度，这里假设软狗触发的时间为20s，那么一般软件看门狗的正常流程如下图示意：

Source: 看门狗机制解析-CSDN博客

总的来说，软件看门狗无需额外的硬件支持，降低了硬件成本，简化了硬件电路设计，但可靠性相对较差，因为一旦系统内部定时器自身发生故障或CPU完全崩溃，软件看门狗可能无法正常工作。

#03

什么内部看门狗与外部看门狗？

在汽车控制器应用工程中，经常采用内部看门狗和外部看门狗共同执行的方案，通常外部看门狗置于电源管理芯片的内部，而内部看门狗置于微控制器中，如下示意：

Source: https://blog.csdn.net/usstmiracle/article/details/130950912

3.1 内部看门狗

内部看门狗是指集成在微控制器或SoC内部的硬件看门狗模块，其工作原理与独立看门狗类似，一般是基于内部的定时器和相关逻辑电路。在系统运行过程中，需要由软件进行喂狗操作，若未及时操作则触发复位。

内部看门狗属于硬件看门狗的一种，利用处理器内部资源实现，与其他内部模块协同工作更紧密，但若微控制器器内部出现严重故障，可能会导致内部看门狗失效。

3.2 外部看门狗

外部看门狗是一个独立于微控制器器的外部硬件设备，通过GPIO、I²C等接口形式与微控制器相连。外部看门狗通常有独立的电源和时钟，微控制器器需要在规定的时间内通过接口向外部看门狗发送喂狗信号，否则外部看门狗将认为系统出现故障，从而触发复位信号，使整个系统重启。

外部看门狗完全独立于主系统，不受主处理器和内部硬件的影响，可靠性极高，能够监控整个硬件平台，适用于对可靠性要求极高的场合，如服务器、工业设备等。

#04 小结

以上我们就介绍各类看门狗的基本概念与原理，从它们的逻辑关系来说，可以做如下小结：

首先，我们可以从硬件依赖程度来做划分，即：

1）硬件看门狗：独立于处理器或系统的主要处理单元之外，拥有自己的时钟源、计数器等硬件资源，其工作原理基于硬件电路和定时器，通过外部硬件的独立运行来实现系统监控，可靠性高，不会因处理器内部故障而完全失效。比如独立看门狗、窗口看门狗、问答型看门狗。

2）软件看门狗：完全依赖处理器的内部资源和软件编程来实现定时和监控功能，没有独立的硬件支持，其工作原理依赖于处理器内部的定时器或其他软件机制。在系统正常运行时通过软件逻辑进行喂狗操作，若系统出现严重故障，如处理器内部时钟故障或软件完全崩溃，则可能无法正常工作。

然后我们还可以从看门狗在系统中的位置来做划分，即：

1）外部看门狗：作为一个独立的硬件设备存在于系统外部，与微控制器通过接口相连。它独立于主系统，有自己的电源和时钟，可以监控整个硬件平台的运行状态，不受主处理器内部故障的影响，具有最高的可靠性，适用于对可靠性要求极高的场合。

2）内部看门狗：集成在微控制器器或 SoC 内部，作为处理器内部的一个模块，它与微控制器的其他内部模块紧密协作，利用微控制器内部的资源实现定时和监控功能。内部看门狗的优点是与系统内部架构高度集成，能够更直接地与内部模块进行交互，但若处理器内部出现严重故障，可能会导致内部看门狗失效。

总的来说，这些分类之间并不是完全独立的，而是相互关联、相互补充的。比如硬件看门狗中的独立看门狗可以是外部看门狗或内部看门狗，具体取决于其在系统中的位置。

Linux消费类设备分层看门狗完整技术方案（含原理、设计、面试答题模板）

一看门狗基础原理

1.1 核心定义

看门狗（Watchdog）是一套倒计时复位机制，分为硬件看门狗、内核软件看门狗、业务层健康监督三层，用于解决 IPC 摄像头、NVR、智能家居网关、电视盒子等 7×24 小时无人值守设备死机、业务假活、内核卡死问题。

底层逻辑：独立计数器持续递减，正常运行时软件定期执行喂狗（清零计数器）；超过设定阈值未喂狗，自动触发整机复位，恢复设备可用性。

1.2 三大类看门狗原理与适用场景

（1）硬件看门狗（HW WDT，最终兜底）

芯片内置独立 RC 振荡器，不依赖系统主时钟、内核调度、用户态进程；内核崩溃、调度卡死、中断屏蔽、应用全死锁时仍能正常计时。

设备节点：/dev/watchdog、/dev/watchdog0（iTCO_wdt、sp5100_tco、平台专用 WDT 驱动）；
关键特性：

nowayout 锁（内核配置 CONFIG_WATCHDOG_NOWAYOUT=y 后，进程崩溃不自动关闭看门狗）；
预超时中断（pretimeout，用于紧急现场保存）；
窗口看门狗（限制喂狗时间窗口，防止异常循环高频喂狗）；

作用：兜底内核/硬件级致命故障，是 IPC 设备最后一道保险。

（2）内核自带软件看门狗（内核健康检测）

Linux 内核内置两套监控，无需外部硬件：

Soft Lockup 软死锁检测：监控单 CPU 长时间不发生调度切换（默认 10s 阈值），检测内核死循环、自旋锁长期持有、高优先级任务抢占不放；触发后打印栈回溯日志，可配置直接 panic 重启。
NMI Hard Lockup 硬死锁检测：利用不可屏蔽中断监控 CPU 完全关中断卡死（连调度器都无法运行），强制生成 crash 日志并复位。

配套工具 **lockdep**：开发期动态检测互斥锁循环等待、锁顺序倒置，提前规避业务死锁根源。

（3）用户态业务监督看门狗（解决业务假活，IPC 核心痛点）

传统方案缺陷：单独定时进程无脑喂硬件狗，即便 IPC 业务死锁、视频流卡死、RTSP 服务阻塞、队列耗尽，喂狗进程仍正常运行，设备呈现“假活不复位”。

核心原理：多维健康心跳聚合，不单一依靠进程存活，同时校验任务执行、业务进度、资源状态、IPC 数据流，所有健康条件满足后才允许喂硬件看门狗，完美覆盖消费 IPC 典型假活故障：

音视频线程互斥锁循环死锁；
高优先级编码任务长期抢占 CPU，低优先级预览/回放线程饥饿；
码流缓冲区、帧池耗尽，生产者消费者互相阻塞；
RTSP/ONVIF 状态机卡死，持续重试但无有效码流输出；
网卡、USB 摄像头总线悬挂，I/O 请求永久等待。

1.3 传统看门狗设计致命缺陷

独立高优先级喂狗进程：仅证明自身能调度，掩盖业务线程饥饿、死锁；
定时循环无条件喂狗：活锁场景下持续喂狗，业务停滞无感知；
仅单一心跳标志位：无法区分“线程运行”和“业务有效完成”；
无预超时现场保存：复位后无法定位死机根因；
无分层恢复机制：轻微业务故障直接整机重启，影响用户体验。

二消费类产品落地分层看门狗完整方案

2.1 整体分层架构（三级防护，从上至下）

业务层健康监督进程（Supervisor）
    ↓ 校验全部业务健康指标 → 允许喂狗
内核层监控（soft/hard lockup + lockdep）
    ↓ 内核异常直接 panic
硬件看门狗（底层兜底，所有软件失效仍生效）

第一层：用户态业务健康 Supervisor

1）受监控业务参与者

所有影响设备核心功能的进程/线程统一注册健康契约：

视频采集线程、H264/H265 编码线程；
RTSP/ONVIF 流媒体服务、录像存储任务；
音频采集、语音对讲线程；
网络管理、SD 卡存储、云台控制进程；
消息队列、帧缓存池、互斥锁资源。

2）双维度心跳上报（区分执行存活 & 业务进度）

每个业务模块分开上报两类单调计数器，杜绝假活误判：

exec_cnt：线程被调度执行即自增（证明 CPU 分配）；
progress_cnt：仅完成有效业务后自增（核心判定依据）：

采集：成功输出一帧有效图像；
编码：完成一帧码流写入缓存；
RTSP：成功发送一帧流、完成客户端握手；
录像：文件正常写入、分段完成；
存储：SD 卡读写请求无阻塞完成。

3）四大维度健康校验规则（Supervisor 周期执行）

Supervisor 以 100ms 周期轮询所有模块快照，全部满足才下发喂狗指令：

执行层校验：各线程 exec_cnt 周期内递增，无 CPU 饥饿；多核 IPC 校验每核调度心跳；
业务进度校验：业务 pending 任务存在时，progress_cnt 必须在业务超时窗口内更新；空闲状态允许进度不变，但需标记无待处理帧/请求；
资源层校验：

互斥锁：记录持有者、最大持有时长，超过阈值判定死锁；
帧缓存/消息队列：队列长期满/空、最旧帧滞留超时限判定流控失效；
内存池：分配失败次数持续上涨判定内存泄漏；

I/O 依赖校验：USB 摄像头、网口、SD 卡无长期悬挂请求，异步操作必须有完成计数。

4）分级恢复策略（减少不必要整机复位）

故障检测后阶梯式自愈，避免轻微故障直接复位 IPC：

L0：单事务重试、清空错误帧缓存；
L1：重启单一流媒体/采集线程，重建会话；
L2：复位 USB/网口外设，重建总线；
L3：重启整套业务子系统（编码 + 流媒体）；
L4：停止喂硬件看门狗，触发整机复位（恢复失败兜底）。

5）预超时故障现场留存

硬件 WDT 开启 pretimeout 预超时中断，复位前以原子/非阻塞方式写入故障快照到 RTC 备份内存 / FRAM：

复位原因、故障模块名称、各线程进度计数器；
锁持有信息、队列水位、滞留帧时长；
CPU 占用、内核 soft lockup 日志、进程栈信息。

重启后应用读取快照，保存到本地日志，用于售后定位死机问题。

6）长操作有界 Lease 机制

IPC 存在 SD 卡格式化、固件 OTA 升级、码流长时间存储等耗时操作，禁止临时关闭看门狗，改用限时授权：

业务申请 lease 并设置最大允许时长，操作中分段上报进度；超时未结束直接判定故障，防止无限延长喂狗窗口。

第二层：Linux 内核监控配置（底层防护）

开启 soft lockup 检测，调整阈值适配 IPC 高负载编码场景：

# /etc/sysctl.conf
kernel.watchdog_thresh=15      # 软死锁判定 15s（适当放宽避免编码负载误报）
kernel.softlockup_panic=1      # 软死锁直接 panic 重启
kernel.hardlockup_panic=1      # NMI 硬死锁直接 panic 重启（务必开启）

开启 NMI 硬死锁看门狗，监控 CPU 完全关中断卡死；
Debug 固件开启 CONFIG_LOCKDEP，运行时打印锁依赖死锁告警；
内核开启 panic_timeout，内核崩溃后 5s 自动重启：
```
kernel.panic=5
```

第三层：硬件看门狗配置（最终兜底）

驱动加载：根据平台加载对应 WDT 驱动，创建 /dev/watchdog 设备；
开启 nowayout：确保内核编译 CONFIG_WATCHDOG_NOWAYOUT=y，防止 Supervisor 进程异常退出后看门狗自动关闭；
超时参数量化设计：

Supervisor 检测周期：100ms，业务最大无进展窗口 3s；
故障恢复预算 2s，快照保存 500ms；
硬件 WDT 总超时设置 8s，预留检测、恢复、日志写入余量；

窗口看门狗启用：限制喂狗窗口，杜绝业务活锁高频重复喂狗。

2.2 Supervisor 进程核心伪代码（Linux 用户态 C 实现）

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <linux/watchdog.h>

// 1. 业务模块健康快照结构体
typedef struct {
    uint32_t exec_cnt;           // 执行心跳
    uint32_t progress_cnt;       // 业务进度心跳
    uint64_t last_progress_ts;   // 最后一次有效业务时间戳
    uint32_t state;              // IDLE / BUSY / DEGRADED / FAILED
} participant_snap_t;

// 2. Supervisor 主循环
void supervisor_loop(void)
{
    int wdt_fd = open("/dev/watchdog", O_RDWR);
    if (wdt_fd < 0) {
        // 降级处理，打印错误并尝试软件模拟复位
        return;
    }

    // 设置硬件超时时间为 8s
    int timeout = 8;
    ioctl(wdt_fd, WDIOC_SETTIMEOUT, &timeout);

    // 【标准写法】通过 SETOPTIONS 开启 nowayout，防止进程退出关闭狗
    int flags = WDIOS_SETNOWAYOUT;
    ioctl(wdt_fd, WDIOC_SETOPTIONS, &flags);

    while (1) {
        collect_all_participant_snap();   // 读取所有业务模块快照
        health_result_t res = evaluate_health(); // 统一健康判定

        if (res.feed_allow) {
            // 标准推荐喂狗方式：ioctl KEEPALIVE（兼容性最佳）
            ioctl(wdt_fd, WDIOC_KEEPALIVE, NULL);
            // 备选：write(wdt_fd, "V", 1);  // 部分平台兼容
            record_feed_epoch();
        } else {
            // 分级自愈
            if (!try_bounded_recovery(&res)) {
                store_crash_snapshot();   // 保存故障现场
                // 停止喂狗，等待硬件 WDT 超时复位（永不 close(fd)）
                while (1) pause();
            }
        }
        usleep(100 * 1000);  // 100ms 检测周期
    }
}

2.3 IPC 产品配套工程化优化

复位风暴防护：RTC 内存保存连续看门狗复位计数，短时间多次复位自动进入安全模式，停止自动录像、降级码流，避免无限重启；
多核适配：多路 IPC 多核平台，每核维护独立调度心跳，Supervisor 校验所有 CPU 活性，防止单核卡死而其他核正常喂狗；
低功耗适配：休眠时临时放宽 WDT 超时，唤醒后重新校验全量业务健康；
权限隔离：仅 Supervisor 进程拥有 /dev/watchdog 读写权限，业务线程禁止直接操作硬件看门狗节点；
故障注入测试：模拟死锁、编码活锁、队列耗尽、CPU 满载，验证所有故障均可在规定时间触发复位并留存日志。

三面试答题完整模板（分基础简答、深度设计题两类）

题型 1：基础题——Linux/嵌入式 IPC 设备看门狗作用、原理、分类

标准作答：

作用：IPC 摄像头、NVR 等 7×24 小时运行设备，出现业务死锁、内核卡死、进程假活、硬件总线悬挂时，自动复位整机，恢复业务可用性，减少人工维护；
基础原理：看门狗是独立倒计时计数器，软件定期喂狗清零；超时未喂狗触发复位；分为硬件、内核、业务三层；
三层分类与分工：

硬件看门狗：芯片独立时钟，兜底内核/调度完全失效场景，不受软件故障影响；
内核看门狗：soft/hard lockup 检测 CPU 卡死，lockdep 开发期检测锁死锁；
用户态业务监督看门狗：解决传统方案“进程存活但业务停滞”的假活问题，多维校验业务进度、资源、数据流；

传统方案缺陷：单一定时进程无脑喂狗，无法识别音视频死锁、流媒体活锁等业务假活故障。

题型 2：深度设计题——IPC 设备如何设计看门狗，规避业务死锁/假活？

分四段作答（逻辑清晰，面试官高分点）

第一段：点明核心痛点

传统仅靠独立任务喂硬件看门狗存在致命漏洞：多线程互斥锁死锁、编码高优先级抢占、流媒体状态机活锁、帧队列耗尽时，喂狗进程仍正常调度，设备假死不复位，IPC 无法预览、录像，用户无感知。因此需要分层健康监督架构，把看门狗从“检测线程存活”升级为“校验业务完整健康”。

第二段：三层整体架构设计

上层：用户态 Health Supervisor 业务监督进程

所有音视频、流媒体、存储业务模块分开上报两类心跳：执行计数、业务完成进度计数；
每 100ms 聚合校验四大维度：线程调度活性、业务进度是否持续推进、锁/队列/内存资源无长期占用、外设 I/O 无悬挂；
故障分级自愈：优先重启单线程/外设，恢复失败再停止喂狗；硬件预超时阶段保存故障快照，便于售后定位死锁根因；
长耗时操作采用有界 Lease，禁止直接关闭看门狗。

中层：Linux 内核原生监控防护

开启 soft lockup、NMI 硬死锁检测，捕获内核自旋锁、关中断卡死；
开发固件开启 lockdep，静态+动态检测互斥锁循环等待，从源头规避死锁；
配置内核 panic 自动重启，覆盖内核崩溃场景。

底层：硬件看门狗最终兜底

加载平台硬件 WDT 驱动，内核开启 CONFIG_WATCHDOG_NOWAYOUT；
量化设置超时时间，预留故障检测、自愈、日志写入余量；启用窗口看门狗，拦截异常循环高频喂狗；
独立 RC 时钟，内核、调度器全部失效仍能正常计时复位。

第三段：死锁/假活专项解决方案

互斥锁死锁监控：封装业务锁，记录持有者、持有时长、等待任务，Supervisor 无锁读取快照，锁持有超阈值判定死锁；开发期 lockdep 校验锁获取顺序，杜绝循环等待；
活锁/CPU 饥饿监控：区分执行心跳与业务进度，线程持续调度但无有效帧输出，超过业务窗口判定活锁；监控多核 Idle 计数，识别高优先级任务长期抢占低优先级关键业务；
队列/缓冲区流控失效：监控队列水位、入队出队计数、最旧帧滞留时间，生产者消费者互相阻塞时触发故障判定；
I/O 外设悬挂：所有 USB、网口、SD 卡异步操作记录完成计数，长期无完成标记判定总线卡死。

第四段：落地工程化保障

限制整机复位次数，复位风暴进入安全降级模式；
故障快照存入 RTC 备份内存，重启后持久化日志；
权限管控，仅 Supervisor 可操作硬件看门狗设备；
全场景故障注入测试，覆盖死锁、活锁、CPU 满载、外设失效等场景，验证检测时效与恢复逻辑。

收尾总结一句话

硬件看门狗做最终复位执行器，内核监控底层调度故障，业务 Supervisor 聚合多维健康证据，只有所有业务链路持续正常推进，才允许喂狗，彻底解决 IPC 设备业务假活、死锁无法复位的痛点。

四总结

针对 Linux消费类设备无人值守、音视频多线程、资源竞争频繁、易出现业务假活的特性，不能仅使用单一硬件看门狗或简单定时喂狗。标准化落地方案采用业务监督 + 内核检测 + 硬件看门狗三层分层架构，通过区分执行心跳与业务进度心跳、监控锁/队列/I/O 资源、分级自愈、预超时现场留存，完整覆盖死锁、活锁、CPU 饥饿、外设悬挂等全部典型故障；同时配套量化超时参数、复位风暴防护、故障日志留存，兼顾设备稳定性与售后问题定位能力，可直接用于 NVR、网络摄像头、智能家居网关量产项目。

posted @ 2022-08-25 10:28 papering 阅读(21) 评论(0) 收藏举报

刷新页面返回顶部

papering