基于Linux的嵌入式系统全程喂狗策略

引 言

在嵌入式系统中，为了使系统在异常情况下能自动恢复，一般都会引入看门狗电路。看门狗电路其实就是一个计数器。当看门狗启动后，计数器开始自动计数，经过一定时间计数器溢出就会对CPU产生一个复位信号使系统重启。系统正常运行时，需要在看门狗允许的时间间隔内对看门狗计数器清零也即喂狗，不让复位信号产生。

当前在带Linux操作系统的嵌入式系统中，由于Linux操作系统加载时间较长(如10～30 s)，一般都超过看门狗的时间间隔(典型值为1.6 s);而如果不采取特殊措施，则系统在Linux操作系统加载过程中复位，Linux操作系统永远无法加载成功。为了解决这个问题，通常有两种方案：做一个看门狗的时间间隔更长的硬件电路;修改内核，在内核启动过程中将看门狗设成无效。以上方案无法解决嵌入式系统在操作系统启动阶段的失效问题，降低了系统可靠性。

本文提出了一种嵌入式系统全程喂狗策略及实现方法，从系统上电、引导程序(Bootloader)、操作系统内核直至应用阶段都启用看门狗。实验表明，该方法简单可行，成本较低，在嵌入式系统的全过程中都可以实现喂狗策略，提高了系统可靠性。

1 系统总体设计

采用IMP706芯片组成硬件看门狗电路(看门狗的时间间隔为1.6 s)，在操作系统程序(包括Bootloader)和应用程序中插入喂狗程序，这些喂狗程序运行时间间隔小于看门狗的时间间隔(本设计选为1 s)。这样做可以保证：如果系统正常工作，系统可以在小于看门狗的时间间隔内不断进行喂狗动作，硬件看门狗的计数器不断清零，不产生复位信号;如果系统非正常工作，喂狗动作失效，硬件看门狗的计数器在1.6 s后溢出，对CPU产生复位信号使系统重启。

1.1 看门狗电路设计

图1为看门狗电路原理，采用IMP706芯片组成硬件看门狗电路，通过电平转换器件74AVClT45，硬件看门狗器件的ST脚与中央处理器 (CPU)的GPIO3脚相连。看门狗器件的PRST脚与IN脚接到复位开关，RST脚接到CPU的RESET脚，当复位开关被触动或看门狗器件的计数器溢出时，看门狗器件的RST脚输出复位信号给CPU的RESET脚，CPU复位重启。

1.2 喂狗策略及实现

1.2.1 Bootloader阶段

在Boot1oader阶段(本设计采用U—boot，但不限于此)，喂狗策略是在Bootloader的程序中不同位置插入喂狗程序。具体做法是：由于Bootoader第一阶段的启动不会超过1.6 s，因此只需在Bootoader的第二阶段，如Flash读写、CRC校验、循环等待等处，插入喂狗代码。喂狗代码采用直接置位中央处理器的GPIO3 状态寄存器的方式进行。

首先在特定平台的定义头文件include/conffigs/xxx.h中加入看门狗的宏定义：

在lib_generic下的CRC校验阶段代码crc32.c中加入如下代码，实现CRC校验阶段喂狗：

1.2.2 Linux内核阶段

在Linux内核加载阶段(采用MontaVista Linux操作系统，但不限于此)，喂狗策略是在Linux内核程序的不同位置插入喂狗程序。具体做法是：首先在Linux内核阶段1的内核解压缩程序、 RTC驱动加载程序、GPIO驱动加载程序适当代码处插入喂狗代码，喂狗代码以直接取反中央处理器的GPIO3状态寄存器的方式进行;在Linux内核阶段2的Watchdog驱动加载程序适当代码处插入喂狗代码，喂狗代码调用GPIO驱动，GPIO驱动内含取反中央处理器的GPIO3状态寄存器的操作;在Linux内核阶段3的内核加载根文件系统程序、init程序的适当代码处调用Linux的Watchdog驱动，Watchdog驱动内含取反中央处理器的GPIO3状态寄存器的操作。

以上内核阶段的划分是以GPIO及Watchdog驱动的加载为标志的。GPIO驱动加载之前为内核阶段1，GPIO驱动加载之后至Watchdog驱动加载之前为内核阶段2，Watchdog驱动加载之后为内核阶段3。

下面示例说明内核解压缩asm/arch/boot/compressed.c中喂狗的实现代码：

从以上代码可以看出，它是内核阶段l喂狗的典型方法，是直接取反GPIO3状态寄存器的。

下面示例说明内核阶段2的喂狗方法(仅以加载RTC驱动为例)：首先让RTC驱动中包含GPIO的头文件，然后在读取RTC当前值的函数中调用GPIO驱动进行喂狗。

为了能够在内核阶段3调用Watchdog驱动进行喂狗，需要在Watchdog驱动中导出喂狗函数以供内核阶段3使用。Watchdog驱动喂狗也是调用GPIO驱动实现的，但Watchdog驱动一旦加载完成，以后的喂狗都通过调用Watchdog驱动完成。

1.2.3 程序运行阶段

图2为多线程应用程序运行阶段喂狗方法。在主程序中首先创建一个监控线程，它的优先级高于其他线程。监控线程在其他被监控的线程正常工作的情况下，一定时间内对看门狗进行喂狗操作，喂狗操作通过调用Watch—dog驱动来完成。如果某个线程出现故障，监控线程就不执行喂狗操作，也就达到这个线程出现故障时系统自动重启的目的。如果监控线程自身出现故障，不能及时执行喂狗操作，看门狗也自动复位重启。具体做法是，主程序首先启动监控线程，然后依次启动N个被监控的线程，每一线程内都设置一计数器。被监控的线程中首先对线程内的计数器初始化为O，在各个线程主循环中，对相应的计数器执行加1操作。监控任务首先启动看门狗，进入循环。每隔M秒对各线程内的计数器进行检验，在M秒内每隔1 s要对看门狗喂狗，否则系统就会复位重启。查询N个计数器值是否为0，如果全都大于0，则说明对应接受监控的线程正常运行，然后对看门狗喂狗，并将N个计数器值清零。如果有任意一个计数器值为O，检测到对应接受监视的线程出现故障需要重启，这时不对看门狗喂狗，使得系统复位重启。[!--empirenews.page--]

以下示例说明在应用中如何调用Watchdog驱动实现喂狗：

总之，在系统不同阶段，由于系统调用和封装程度不同，看门狗的喂狗实现方法也不同：在Bootloader阶段，直接取反中央处理器的 GPIO3的状态寄存器;在Linux内核阶段1，采取取反中央处理器的GPIO3的状态寄存器的方法进行;在Linux内核阶段2，采取调用GPIO的驱动的方法进行;在Linux内核阶段3，采取调用Watchdog驱动的方法进行;在应用程序运行阶段，应用程序中的喂狗程序采取调用Watchdog 驱动的方法进行，如图3所示。

2 实验结果

我们在公司研发的智能视频分析器项目中应用了本方法。该分析器采用TI DaVinci系列DSP芯片(TMS320DM6446)为CPU，用Monta Vista Linux作为操作系统。操作系统启动时间约为20～30 s。采用本方法是为了保证系统在全过程中都能得到有效的失效恢复。在振荡波抗扰度、电压波动与闪烁、静电放电、电快速瞬变脉冲群等EMC兼容性测试中，当各强度指标超过设备EMC兼容性设计强度时，系统失效，利用这种方式可以测试本方法在硬件失效时的效果。以静电放电为例，设计放电等级为±6 kV(我们取±7 kV的强度等级)，设备上电后，分别在1～30 s内每隔5 s及在120 s处进行静电放电测试，经观察设备都可以即时恢复。

对软件失效时本方法效果的测试，采用故障植入脚本的主动方式及系统长时间运行的被动方式进行测试。最终结果表明，设备在失效后可即时恢复。

综上所述，本全程喂狗的方法能确保系统在任一阶段出现软件或硬件故障时都能复位重启。

结 语

本文提出了一种嵌入式系统全程喂狗策略，包括硬件电路设计和软件实现方法。该方法有如下特点：看门狗电路简单，硬件只需一块看门狗芯片，不需复杂的外围逻辑电路，成本较低;系统全过程启用看门狗，确保系统在任一阶段出现软件或硬件故障都能复位重启，系统可靠性得到提高。