一、WWDG 简介

窗口看门狗通常被用来监测由外部干扰或不可预见的逻辑条件造成的应用程序背离正常的运行序列而产生的软件故障。除非递减计数器的值在T6 位变成 0前被刷新，看门狗电路在达到预置的时间周期时，会产生一个MCU 复位。在递减计数器达到窗口寄存器数值之前，如果 7位的递减计数器数值（在控制寄存器中）被刷新，那么也将产生一个MCU 复位。这表明递减计数器需要在一个有限的时间窗口中被刷新。

二、WWDG 主要特征

  •   可编程的自由运行递减计数器

  •   条件复位

      - 当递减计数器的值小于 0x40，（若看门狗被启动）则产生复位。
      - 当递减计数器在窗口外被重新装载，（若看门狗被启动）则产生复位。

  •   如果启动了看门狗并且允许中断，当递减计数器等于0x40 时产生早期唤醒中断（EWI），它可以被用于重装载计数器以避免WWDG 复位。

三、WWDG功能描述

如果看门狗被启动（WWDG_CR寄存器中的WDGA 位被置1），并且当 7位（T[6：0]）递减计数器从0x40 翻转到0x3F（T6位清零）时，则产生一个复位。如果软件在计数器值大于窗口寄存器中的数值时重新装载计数器，将产生一个复位。

应用程序在正常运行过程中必须定期地写入WWDG_CR 寄存器以防止MCU 发生复位。只有当计数器值小于窗口寄存器的值时，才能进行写操作。储存在WWDG_CR 寄存器中的数值必须在0xFF 和0xC0 之间：

1、启动看门狗

在系统复位后，看门狗总是处于关闭状态，设置WWDG_CR 寄存器的WDGA 位能够开启看门狗，随后它不能再被关闭，除非发生复位。

2、控制递减计数器

递减计数器处于自由运行状态，即使看门狗被禁止，递减计数器仍继续递减计数。当看门狗被启用时，T6 位必须被设置1，以防止立即产生一个复位。

T[5：0]位包含了看门狗产生复位之前的计时数目；复位前的延时时间在一个最小值和一个最大值之间变化，这是因为写入WWDG_CR寄存器时，预分频值是未知的。

配置寄存器（WWDG_CFR）中包含窗口的上限值：要避免产生复位，递减计数器必须在其值小于窗口寄存器的数值并且大于0x3F 时被重新装载，上图描述了窗口寄存器的工作过程。

另一个重装载计数器的方法是利用早期唤醒中断（EWI）。设置WWDG_CFR 寄存器中的WEI 位开启该中断。当递减计数器到达0x40 时，则产生此中断，相应的中断服务程序（ISR）可以用来加载计数器以防止WWDG 复位。

在WWDG_SR 寄存器中写0可以清除该中断。注：T6 位可以被用来产生一个软件复位（WDGA 位被置位，T6 位清零）

四、如何编写看门狗超时程序

下图显示了装载到看门狗计数器（CNT）中的 6 位计数值和看门狗的延迟时间之间的线性关系（以 mS为单位）。此图可用来做为快速计算的参考，而未将时间的偏差考虑在内。如果需要更高的精度，可以使用下图提供的计算公式。

当写入 WWDG_CR 寄存器时，始终置 T6 位为1以避免立即产生一个复位。

五、设置WWDG实验分析

  •   实验内容简介
环境MM32L073PF Miniboard、MDK，设置WWDG，通过观察喂狗与不喂狗的复位现象。

  •   实验代码分析
首先看main函数

先初始化一个串口，方便我们观察复位现象，然后通过函数Wwdg_reset_ON 进行设置WWDG。最后在循环里通过WWDG_SetCounter函数不停的喂狗。

在函数Wwdg_reset_ON中设置窗口值，和计数器的初值。

  •   实验现象
1、当注释掉喂狗函数时，通过串口在不断打印可以看出，MCU一直在复位。
2、当不注释喂狗函数时，串口只打印一次，MCU没有复位。

独立看门狗（iwdg）

一、简介：

其用于检测和解决由软件错误导致的故障，当计数器达到设定的超时时间值时会产生系统复位。其特点为：1、其运用的时钟是由独立的RC振荡器产生的，因此可以在待机和停止模式下运行。2、在看门狗激活后，如果递减计数器的值达到0X000时会产生系统复位。

二、功能简述：

通过向关键字寄存器（IWDG_KR）写入0XCCCC启动独立看门狗，计数器会从复位值0XFFF，递减计数，当计数器的值达到0X000时，产生复位信号。在计数值还未达到0X000时，向IWDG_KR寄存器写入0XAAAA，IWDG_RLR寄存器的值就会重装载到计时器，从而可以避免产生复位（俗称喂狗）。从而可以看出，当软件运行出问题时，在一定的时间内无法做到喂狗的功能时，就会产生系统复位，实现其对软件故障的检测和解决。

三、相关寄存器：

1、关键字寄存器：

关键字寄存器的有效位为位0到位15，位16到位31保留，前边已经介绍过通过向该寄存器中写入0XAAAA，可以使IWDG_RLR寄存器中的值重装载到计数器，避免系统复位。由于IWDG_PR（预分频器寄存器）和IWDG_RLR（重载寄存器）是具有写保护的寄存器，在该寄存器中写入键值0X5555可使能对IWDG_PR和IWDG_RLR的访问。

2、预分频器寄存器：

该寄存器的有效位为位0到位2，其他位保留，通过设置PR[2:0]的值，设定相应的分频系数。

3、重载寄存器：

上面已经提到该寄存器中的值会重装载到计数器中，计数器将会从该值递减计数，由此可见：该寄存器中的值和预分频器寄存器中的值共同决定超时周期。

4、状态寄存器：

该寄存器只有位0和位1为有效位，位0（RVU）为预分频器寄存器的值更新标志位，位1（PVU）为计数器重载值更新标志。

四、相关代码分析：

通过相关库函数对独立看门狗的配置还是相对简单的，其中初始化的过程如下：

IWDG_WriteAccessCmd(IWDG_WriteAccess_Enable); //使能对IWDG->PR IWDG->RLR的写

IWDG_SetPrescaler(prer); //设置IWDG分频系数

IWDG_SetReload(rlr); //设置IWDG装载值

IWDG_ReloadCounter(); //reload（喂狗）

IWDG_Enable(); //使能看门狗

窗口看门狗（wwdg）

一、简介：

对比独立看门狗来看，所谓的窗口看门狗就是设定了一个窗口值（上限和下限值）。当递减计数器值小于0X40（窗口下限值）时产生复位。在设置的窗口外重载递减计数器也会执行复位。窗口看门狗可以设置提前唤醒中断，当递减计数器等于0X40时会触发该中断，可以在该中断中做喂狗等相关操作。

二、框图：

窗口看门狗的框图如下：对比的框图来看下边的相关介绍！

三、工作过程：

通过设置WWDG_CR寄存器的WDGA位可以使能看门狗，递减计数器为控制寄存器的低7位，其中当第7位（即T6）由1变为0（即由0X40递减为0X3F）时就会复位，在配置寄存器低7位存放看门狗上限值，计数器中的值与上限值比较，如果在上限值之上喂狗也会执行复位，这也是窗口看门狗与独立看门狗的不同之处。由此可见，喂狗的时间只能在上限和下限值之间，否则就会执行复位操作。

四、相关寄存器：

1、控制寄存器（WWDG_CR）：

前面已经介绍过了，其中有效位为位0到位7，位7（WDGA）为看门狗激活位，位0到位6做计数器。

2、配置寄存器（WWDG_CFR）：

该寄存器的有效位为位0到位9，位0到位6前面已经介绍过存放的是计数器的上限值，位7和位8用来设置定时器时基，从而选定相应的时钟分频器。其中位9就是上边介绍到的提前唤醒中断（EWI）。

3、状态寄存器（WWDG_SR）：

该寄存器中的有效位只有位0，用来做提前唤醒中断的标志位（EWIF）。

看门狗分硬件看门狗和 软件看门狗。硬件看门狗是利用一个定时器电路，其定时输出连接到电路的复位端，程序在一定时间范围内对定时器清零(俗称“喂狗”)，因此程序正常工作时， 定时器总不能溢出，也就不能产生复位信号。如果程序出现故障，不在定时周期内复位看门狗，就使得看门狗定时器溢出产生复位信号并重启系统。软件看门狗原理 上一样，只是将硬件电路上的定时器用处理器的内部定时器代替，这样可以简化硬件电路设计，但在可靠性方面不如硬件定时器，比如系统内部定时器自身发生故障 就无法检测到。当然也有通过双定时器相互监视，这不仅加大系统开销，也不能解决全部问题，比如中断系统故障导致定时器中断失效。

看门狗本身不是用来解决系统出现的问题，在调试过程中发现的故障应该要查改设计本身的错误。加入看门狗目的是对一些程序潜在错误和恶劣环 境干扰等因素导致系统死机而在无人干预情况下自动恢复系统正常工作状态。看门狗也不能完全避免故障造成的损失，毕竟从发现故障到系统复位恢复正常这段时间 内怠工。同时一些系统也需要复位前保护现场数据，重启后恢复现场数据，这可能也需要一笔软硬件的开销。

在单任务系统中看门狗工作原理如上所述，容易实现。在多任务系统中情况稍为复杂。假如每个任务都像单任务系统那么做，如图1(a)所示，只要有一个 任务正常工作并定期“喂狗”，看门狗定时器就不会溢出。除非所有的任务都故障，才能使得看门狗定时器溢出而复位，如图1(b)。

而往往我们需要的是只要有一个任务故障，系统就要求复位。或者选择几个关键的任务接受监视，只要一个任务出问题系统就要求复位，如图2(a)所示，相应的看门狗复位逻辑如图2(b)所示。

在多任务系统中通过创建一个监视任务TaskMonitor，它的优先级高于被监视的任务群Task1、Task2...Taskn。 TaskMonitor在Task1~Taskn正常工作情况下，一定时间内对硬件看门狗定时器清零。如果被监视任务群有一个Task_x出现故 障，TaskMonitor就不对看门狗定时器清零，也就达到被监视任务出现故障时系统自动重启的目的。另外任务TaskMonitor自身出故障时，也 不能及时对看门狗定时器清零，看门狗也能自动复位重启。接下来需要解决一个问题是：监视任务如何有效监视被监视的任务群。

在TaskMonitor中定义一组结构体来模拟看门狗定时器组，

typedef struct

{

UINT32 CurCnt, LastCnt;

BOOL RunState;

int taskID;

} STRUCT_WATCH_DOG;

该结构体包括被监视的任务号taskID，用来模拟“喂狗”的变量CurCnt、LastCnt(具体含义见下文)，看门狗状态标志RunState用来控制当前任务是否接受监视。

被监视的任务Task1~Taskn调用自定义函数CreateWatchDog(int taskid)来创建看门狗，被监视任务一段时间内要求“喂狗”，调用ResetWatchDog(int taskid)，这个“喂狗”动作实质就是对看门狗定时器结构体中的变量CurCnt加1操作。TaskMonitor大部分时间处于延时状态，假设硬件 看门狗定时是2秒，监视任务可以延时1.5秒，接着对创建的看门狗定时器组一一检验，延时前保存CurCnt的当前值到LastCnt，延时后比较 CurCnt与LastCnt是否相等，都不相等系统才是正常的。需要注意的是CurCnt和LastCnt数据字节数太小，而“喂狗”过于频繁，可能出 现CurCnt加1操作达到一个循环而与LastCnt相等。

如果有任意一组的CurCnt等于LastCnt，认为对应接受监视的任务没有“喂狗”动作，也就检测到该任务出现故障需要重启，这时候 TaskMonitor不对硬件看门狗定时器清零，或者延时很长的时间，比如10秒，足以使得系统重启。反之，系统正常，Task1~Taskn定期对 TaskMonitor“喂狗”，TaskMonitor又定期对硬件看门狗“喂狗”，系统就得不到复位。还有一点，被监视任务可以通过调用 PauseWatchDog(int taskid)来取消对应的看门狗，实际上就是对STRUCT_WATCH_DOG结构体中的RunState操作，该标志体现看门狗有效与否。

这种方式可监视的最大任务数由STRUCT_WATCH_DOG结构数据的个数决定。程序中应该有一个变量记录当前已创建的看门狗数，判断被监视任务Task1~Taskn是否“喂狗”只需比较CurCnt与LastCnt的值n次。

硬件看门狗监视TaskMonitor任务，TaskMonitor任务又监视其他的被监视任务Task1~Taskn，形成这样一种链条。这种方 式系统的故障图表示如图3所示。被监视任务Task1~Taskn及TaskMonitor都是或的关系，因此被监视的任一任务发生故障，硬件电路看门狗 就能复位。

为实现多任务系统的看门狗监视功能额外增加了TaskMonitor任务，这个任务占用执行时间多少也是一个重要问题。假设 TaskMonitor任务一个监视周期延时1.5秒，此外需要执行保存当前计数值，判断是否“喂狗”等语句，它的CPU占用时间是很小的。用一个具体的 试验证实，使用50M工作频率的CPU(S3C4510)，移植vxWorks操作系统，cache不使能条件下监视10个任务，每个监视周期占用 220~240微秒。可见该任务绝大多数时间都处于任务延时状态。

被监视任务可能有获取消息、等待一个信号量等的语句，往往这个消息、信号量的等待是无限期的等待。这就需要将这类语句作一些修改。比如在vxWorks中将一次无期限的获取信号量操作

semTake(semID, WAIT_FOREVER); // WAIT_FOREVER为无限时间等待

分解为

do

{

ResetWatchDog; // “喂狗”操作

}while(semTake(semID, sysClkRateGet( )) != OK); // 1s内的等待信号量操作

多次的时间范围内的获取信号量操作，这样才能保证及时“喂狗”。

另外需要注意的是系统中是否有的任务优先级比TaskMonitor高并且长时间处于执行状态，TaskMonitor长时间得不到调度，使得看门狗错误复位。良好的任务划分，配置是不应该出现这种高优先级任务长期执行状况的。