概述
看门狗一般分为硬件看门狗和软件看门狗，主要用来解决程序CPU异常，程序跑飞挂死等问题，提高系统的可靠性。
硬件看门狗是利用一个定时器电路，其定时输出连接到电路的复位端，程序在一定时间范围内对定时器清零(俗称“喂狗”)，因此程序正常工作时，定时器总不能溢出，也就不能产生复位信号。如果程序出现故障，不在定时周期内复位看门狗，就使得看门狗定时器溢出产生复位信号并重启系统。软件看门狗原理上一样，只是将硬件电路上的定时器用处理器的内部定时器代替，这样可以简化硬件电路设计，但在可靠性方面不如硬件定时器，比如系统内部定时器自身发生故障就无法检测到。当然也有通过双定时器相互监视，这不仅加大系统开销，也不能解决全部问题，比如中断系统故障导致定时器中断失效。
看门狗本身不是用来解决系统出现的问题，在调试过程中发现的故障应该要查改设计本身的错误。加入看门狗目的是对一些程序潜在错误和恶劣环境干扰等因素导致系统死机而在无人干预情况下自动恢复系统正常工作状态。看门狗也不能完全避免故障造成的损失， 毕竟从发现故障到系统复位恢复正常这段时间内怠工。同时一些系统也需要复位前保护现场数据，重启后恢复现场数据，这可能也需要一笔软硬件的开销。
单任务系统
程序一般都是一个大循环，没有任务调度，只要在初始化阶段开启看门狗，然后在大循环程序内部合适的地方进行看门狗定时器清零即可，比较容易实现。
独立看门狗一般用来检测和解决由程序引起的故障，比如一个程序正常运行的时间是50ms，在运行完这个段程序之后紧接着进行喂狗，我们设置独立看门狗的定时溢出时间为60ms，比我们需要监控的程序 50ms 多一点，如果超过 60ms 还没有喂狗，那就说明我们监控的程序出故障了，跑飞了，那么就会产生系统复位，让程序重新运行。
硬件设计：
1-IWDG，属于内部资源，无需外部硬件
2-KEY 一个
3-LED 两个，用开发板自带的RGB灯即可
main函数如下，其他的参考正点原子手册
int main(void)
{/* LED 端口初始化 */LED_GPIO_Config(); delay_ms(500); /* 检查是否为独立看门狗复位 */if (RCC_GetFlagStatus(RCC_FLAG_IWDGRST) != RESET){/* 独立看门狗复位 *//* 亮红灯 */LED_RED;/* 清除标志 */RCC_ClearFlag();/*如果一直不喂狗，会一直复位，加上前面的延时，会看到红灯闪烁在1s 时间内喂狗的话，则会持续亮绿灯*/}else{/*不是独立看门狗复位(可能为上电复位或者手动按键复位之类的) *//* 亮蓝灯 */LED_BLUE;} /*初始化按键*/Key_Init(); // IWDG 1s 超时溢出IWDG_Config(4 ,625); //while部分是我们在项目中具体需要写的代码，这部分的程序可以用独立看门狗来监控//如果我们知道这部分代码的执行时间，比如是500ms，那么我们可以设置独立看门狗的//溢出时间是600ms，比500ms多一点，如果要被监控的程序没有跑飞正常执行的话，那么//执行完毕之后就会执行喂狗的程序，如果程序跑飞了那程序就会超时，到达不了喂狗的//程序，此时就会产生系统复位。但是也不排除程序跑飞了又跑回来了，刚好喂狗了，//歪打正着。所以要想更精确的监控程序，可以使用**窗口看门狗**，窗口看门狗规定必须//在规定的窗口时间内喂狗。while(1) { if( Key_Scan(KEY1_GPIO_PORT,KEY1_PIN) == KEY_ON ){// 喂狗，如果不喂狗，系统则会复位，复位后亮红灯，如果在1s// 时间内准时喂狗的话，则会亮绿灯IWDG_Feed(); //喂狗后亮绿灯LED_GREEN;}}
}
程序先检查是否为独立看门狗复位，如果是独立看门狗复位亮红灯。如果一直不喂狗，会一直kanmeng 复位，加上前面的延时，会看到红灯闪烁，在1S时间内喂狗的话，则会持续亮绿灯。
多任务系统中
一般结合嵌入式操作系统，设置一个优先级级别最高的任务作为监视器，以监视各个应用任务是否正常运行，该监视器即为软件看门狗，该任务对其他任务都设定一个计时器，每个被监视的任务在设定的时间内对软件看门狗中相应的定时器定时清零，即喂软狗，在其他任务都正常工作的情况下，软件看门狗对内置的硬件看门狗定时器周期性清零，即喂狗。
在多任务系统中通过创建一个监视任务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任务又监视其他的被监视任务Task1Taskn，形成这样一种链条。这种方式系统的故障图表示如图3所示。被监视任务Task1Taskn及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长时间得不到调度，使得看门狗错误复位。良好的任务划分，配置是不应该出现这种高优先级任务长期执行状况的。
转自：博客1
博客2
