【转】嵌入式系统中看门狗的使用总结

只看该作者 · 2017-1-12 12:27

最近需要在板子上加上一块WatchDog，以确保在系统出错时自动重启，所以看了一些在嵌入式系统中使用看门狗的资料，现在总结如下：

一、看门狗原理
在产品化的嵌入式系统中，为了使系统在异常情况下能自动复位，一般都需要引入看门狗。
看门狗其实就是一个可以在一定时间内被复位的计数器。当看门狗启动后，计数器开始自动计数，经过一定时间，如果没有被复位，计数器溢出就会对CPU产生一个复位信号使系统重启（俗称“被狗咬”）。系统正常运行时，需要在看门狗允许的时间间隔内对看门狗计数器清零（俗称“喂狗”），不让复位信号产生。如果系统不出问题，程序保证按时“喂狗”，一旦程序跑飞，没有“喂狗”，系统“被咬”复位。
这就好比你的身边有一只时刻饥饿的狗，你不按时给它肉吃，它就会吃你的肉，你被吃了......挂了，投胎转世，彻底重新做人了。不幸的是来世你还得喂狗-_-!!

二、看门狗的种类
在现在的嵌入式系统中主要可以分为两种类型的看门狗：
1、CPU内部自带的看门狗：此类看门狗一般是将一个芯片中的定时器来作为看门狗，通过程序的初始化，写入初值，设定溢出时间，并启动定时器。程序按时对定时器赋初值（或复位），以免被咬。这种看门狗是可以被禁用的（只要停止这个定时器即可），好比对那只要咬你的狗来个“葵花点穴手”。大部分CPU都内置看门狗，硬件原理可参考各芯片数据手册。
   优点：可以通过程序改变溢出时间；可以随时禁用
缺点：需要初始化；如果程序在初始化、启动完成前跑飞或在禁用后跑飞，看门狗就无法复位系统，这样看门狗的作用就没有了，系统恢复能力降低。

   2、独立的看门狗芯片：这种看门狗主要有一个用于喂狗的引脚（一般与CPU的GPIO相连）和一个复位引脚（与系统的RESET引脚相连），如果没有在一定时间内改变喂狗脚的电平，复位引脚就会改变状态复位CPU。此类看门狗一上电就开始工作，无法禁用。现在常用的芯片有：CAT705/CAT706、IMP706等等，溢出时间在1.6秒左右。硬件原理可以参考各芯片数据手册和《基于Linux的嵌入式系统全程喂狗策略》。
优点：无须配置，上电即用。无法禁用，系统必须按时喂狗，系统恢复能力高。
  缺点：无法灵活配置溢出时间，无法禁用，灵活性降低。

------------------------------------------------

当然还有所谓的软件看门狗，这其实是也是一种监控软件。
一些重要的程序，必须让它一直跑着；而且还要时时关心它的状态——不能让它出现死锁现象。（当然，如果一个主程序会出现死锁，肯定是设计或者编程上的失误。首要做的事是Debug。）但如果时间紧迫可以用软件看门狗，暂时应急。
这种监控软件运行不出现界面窗口，具有一定的隐蔽性；它定时判断目标进程是否运行在当前系统中，如果没有则启动目标进程；判断目标进程是否“无响应”，如果是则终止目标进程；如果目标进程“无响应”的次数超过一定的数量，则重启整个系统。它的目的也是复位，但是它主要市复位进程，实在不行才复位CPU。
这种软件属于监控软件，不在本文的叙述范围之内。

------------------------------------------------
三、看门狗的选择
在一般的民用产品，对系统的稳定性没有太高要求的场合，可以使用内置看门狗，可以简化软件开发和硬件成本。
在工控产品和对系统的稳定性有较高要求的关键场合，基本都选用硬件独立看门狗，确保系统在面对严重错误时的恢复能力。增加了硬件成本，稍微加大了软件的开发难度（必须确保在正常情况下的不断喂狗）。

----------------------------------------------------------
四、在bootloader下的使用
如果是CPU内置的看门狗，一般在这阶段可以禁用，所有没什么特殊的操作。
但是如果是独立的看门狗芯片就必须喂了。或者为了保险，你在bootloader中就启动了看门狗，也得喂了。
bootloader有很多，基本原理都是一样的，喂狗的过程也基本一样，在这里以uboot为例讲解如何喂狗。
u-boot的运行分为以下几个阶段：

最早的简单初始化，代码重定位的自拷贝阶段
系统详细初始化阶段
控制台阶段（如果使用了自动启动，则跳过）
OS内核拷贝（可能带有解压过程），跳入操作系统

（待完善）

五、在Linux下使用
在bootloader加载了内核之后，系统就开始由Linux内核接管。而喂狗的工作自然也开始由内核来承担。在bootloader将控制权给内核之后，时间上可以分为以下几个部分：

内核自解压阶段（压缩内核才有：zImage或bzImage）
内核启动到看门狗驱动加载之前
看门狗驱动加载后到根文件系统启动前
根文件系统启动后到看门狗守护进程启动前
看门狗守护进程启动后

对于使用CPU内置的看门狗，在1～4阶段，看门狗一般都没有启动，无需喂狗。只有在看门狗守护进程启动后，由守护进程打开看门狗，并根据配置文件监控其他进程的状态来开始喂狗。如果被监控进程出现不可修复的问题，守护进程停止喂狗，CPU复位。

对于独立的看门狗芯片，系统一上电就必须不断喂狗，接过bootloader的接力棒继续喂狗。
首先在第1阶段，内核的自解压一般时间较长，必须在自解压的循环过程中加入喂狗代码（可能还要是汇编形式的）。一旦在这过程中跑飞，就不会喂狗，CPU复位。

在第2阶段，这段时间一般不会很长，可以不用喂狗。但是这也和你的内核有关，如果在这个阶段正好有比较耗时的模块启动的话，你可以在这个模块的初始化函数或者比较耗时的循环和等待中添加喂狗代码。具体在哪些模块中加，要尝试启动几次就知道了，靠实验和经验。

在看门狗驱动加载时，一般会在模块初始化代码中喂一次狗。

在第3阶段，和第2阶段类似，如果在这个阶段正好有比较耗时的模块启动的话，你可以在这个模块的初始化函数或者比较耗时的循环和等待中添加喂狗代码。但是在根文集系统挂载时，根据文件系统的性质和大小，可能需要在文件系统代码中添加喂狗指令。

第4阶段是一个比较耗时的阶段，一般会在系统启动脚本中添加一些简单的喂狗的shell命令，例如：“echo V > /dev/watchdog”，加的位置根据系统的启动过程而异。

在第5阶段，一切都由看门狗守护进程来实现喂狗了。

-----------------------------------------------------------------------------

内核看门狗的框架分析

（待续）

------------------------------------------------------------------------------

其实对于看门狗在Linux系统中的使用还有一种形式是双狗：

在内核中用内核线程硬件的看门狗，这个硬件看门狗的作用在于保证内核宕机时可以复位。

在内核产生软件看门狗，用守护进程或者需要监控的进程去喂狗，这个看门狗保证关键进程可以复位。

推荐参考资料：
看门狗驱动：

linux/drivers/watchdog ：其中包含所有看门狗驱动：

watchdog_core.c、watchdog_dev.c和watchdog_dev.h是内核看门狗的框架核心，看门狗的驱动当然最好是在这个框架下编写比较好。但是好像其中的驱动并不都只这样。、

linux/Documentation/watchdog/watchdog-kernel-api.txt 内核看门狗框架API说明文档

内核看门狗驱动官网