看门狗基础概念

大家好，我是老张。在嵌入式领域摸爬滚打了十几年，今天咱们来聊聊看门狗——这个看似简单、实则暗藏玄机的基础话题。

说实话，我刚入行那会儿，觉得看门狗就是个定时器，喂喂狗就完事了。直到有一次，我在一个量产项目中因为看门狗配置不当，导致ECU在高温环境下频繁复位……嗯，那教训够我记一辈子的。

什么是看门狗？

看门狗，英文叫Watchdog Timer，简称WDT。说白了，它就是一个特殊的计数器。

这个计数器会一直往下数。数到零的时候，它就干一件事——复位系统。

那怎么避免它数到零呢？很简单，在它数完之前，你给它重新赋值，让它重新开始数。这个动作，我们叫“喂狗”。

你想想看，如果程序跑飞了、死循环了、或者卡在某个中断里出不来了，谁去喂狗？没人喂。那看门狗就会超时，然后强制复位整个系统。

这就是看门狗最核心的作用——在系统失控时，把它拉回来。

看门狗在ECU中的作用

在汽车ECU里，看门狗的地位可不一般。我参与过好几个符合ISO 26262功能安全标准的项目，每个项目里，看门狗都是安全机制中的关键一环。

具体来说，看门狗在ECU中主要干这几件事：

• 检测程序跑飞——CPU执行了非法指令，或者PC指针跳到了不该去的地方
• 检测死循环——某个任务卡住了，其他任务得不到执行
• 检测中断异常——中断频繁触发，或者中断服务程序执行时间过长
• 检测任务调度异常——在RTOS环境下，某个高优先级任务霸占了CPU
• 提供系统恢复途径——一旦检测到异常，自动复位让系统重新来过

我记得有一次，客户反馈说某款ECU在低温启动时偶尔会死机。查了很久，最后发现是看门狗的超时时间设置得太短，导致正常启动流程还没跑完就被复位了。你看，看门狗用不好，反而会引入新问题。

硬件看门狗与软件看门狗的区别

这个问题，我面试新人的时候经常问。很多人觉得区别就是“一个用硬件实现，一个用软件实现”。嗯，对了一半。

咱们来仔细看看：

对比项	硬件看门狗	软件看门狗
实现方式	独立的硬件模块，通常集成在MCU内部	利用软件定时器或任务调度机制实现
可靠性	高，独立于CPU运行	低，依赖CPU和软件正常工作
超时处理	直接复位系统，不可被软件屏蔽	可自定义处理方式，如记录日志、尝试恢复
灵活性	低，超时时间固定或有限可配	高，可动态调整超时时间和喂狗策略
适用场景	安全关键系统，如动力域、底盘域ECU	非安全关键系统，或作为硬件看门狗的补充

我个人习惯的做法是：硬件看门狗保底，软件看门狗做精细化管理。

什么意思呢？

硬件看门狗设置一个较长的超时时间，比如500ms。它只负责一件事——如果系统彻底挂了，就强制复位。

软件看门狗呢？我可以在每个任务里都放一个喂狗点。如果某个任务超时了，软件看门狗先尝试恢复，比如重启那个任务。实在不行了，再让硬件看门狗出手。

我曾经在一个项目中，只用软件看门狗。结果呢？程序跑飞了，软件看门狗自己都跟着飞了，根本没人去触发复位。从那以后，我再也不敢只用软件看门狗了。

最后说一句，看门狗的超时时间怎么定？我一般遵循“正常执行时间的2-3倍”这个原则。太短了容易误触发，太长了起不到保护作用。当然，具体还要看你的系统实时性要求。

好了，这一章就聊到这儿。下一章咱们深入讲讲看门狗超时的具体原因分析，到时候我会分享几个我踩过的坑，保证让你少走弯路。