来源：公众号【鱼鹰谈单片机】
作者：鱼鹰Osprey
stm32基本都内置两种看门狗（另外还有外置的看门狗芯片），窗口看门狗和独立看门狗，两种看门狗的使用方法和应用场景各不相同，今天主要讲讲最常用的独立看门狗（工作这么多年，没见谁用过窗口看门狗，这种估计在时序严格的场合会用上）。
所谓独立（Independent watchdog），就是该看门狗有独立的时钟源供看门狗使用，VIP专属。这样即使程序跑飞，或者主时钟挂掉，照样运行。但是精度嘛，你懂的（VIP用户一般比较飘）。
所谓看门狗，外形虽然不像（一堆电子电路，肯定不像），但行为真的狗，还是一条疯狗。为啥这么说呢？
这只狗一定要在规定以内的时间（这个时间自己设置）喂食，超出一点都不行，否则就咬人（复位整个程序，让你的人生重新来过）
但是疯狗用的好，就是一条专业的好狗，比谁都敬业（虽然会有点飘哈，因此喂狗的时间不能卡太死，需要有充足的余量）。所以绝大部分产品都会用上看门狗，以防意外情况发生，可以有重头再来的机会。
但是喂狗也有方法，不能随便喂，不然狗的行为就不专业了（该复位的时候不复位）。所以需要专业的调教。
比如，喂狗的地方一般只有一个地方，并且是一定会执行的。
裸机时，一般放主循环while（1）里面定时执行（没必要太频繁）。
RTOS时，一般放在优先级最低的任务中执行，或者空闲任务中（使用钩子函数）。
千万千万不要在中断处理程序中喂狗，因为可能你的主程序已经跑死，中断还好好的运行呢（如果要用中断触发，可以在中断处理程序中只设置一个变量标志位，然后在另外位置判断标志位决定是否喂狗）。
但是看门狗只是一个预防措施，而不是一个正常行为，因此开发过程中，一定要关注看门狗是否出现复位现象，只要出现一次，都要揪出问题的根本原因，否则到了市场上一定会复位的。
引起程序复位的原因有很多种，比如上电、掉电，那么如何看是否由看门狗引起的呢？有个寄存器是可以看到具体原因的，比如stm32f1 （其他的可以自己查手册）
代码实现：
hw_cpu_reset_flag_t hw_cpu_reset_get(void)
{
hw_cpu_reset_flag_t temp = {.value = 0};// 自定义的一个结构变量，方便使用
if(RCC_GetFlagStatus(RCC_FLAG_PORRST) != RESET)
{
temp.flag.power = 1;
}
if(RCC_GetFlagStatus(RCC_FLAG_LPWRRST)!= RESET)
{
temp.flag.low_power = 1;
}
if(RCC_GetFlagStatus(RCC_FLAG_PINRST) != RESET)
{
temp.flag.pin_reset = 1;
}
if(RCC_GetFlagStatus(RCC_FLAG_SFTRST)!= RESET)
{
temp.flag.software_reset = 1;
}
if(RCC_GetFlagStatus(RCC_FLAG_IWDGRST) != RESET)
{
temp.flag.independent_dog = 1;
}
if(RCC_GetFlagStatus(RCC_FLAG_WWDGRST)!= RESET)
{
temp.flag.window_dog = 1;
}
RCC_ClearFlag();//清除RCC中复位标志
return temp;
}另外在调试过程中，我们可以一开始就禁用看门狗（一般在调试寄存器中）比如 :
DBGMCU_Config (DBGMCU_IWDG_STOP, ENABLE);这样即使程序因调试而长时间暂停，也不会产生复位，否则看门狗复位，会影响调试。
需要注意的是，即使在在线调试环境下，一旦全速运行，如果程序喂狗不及时，仍然会引起复位（这也是我们希望的，可以在调试过程中发现喂狗是否有问题）《代码调着调着就失联了》
如果我们的代码已经下载到单片机，但又没用设置该位，如果你采用鱼鹰之前介绍的抓现场环境的方法（关键字 颠覆认知），那么也可能会引起看门狗的复位，因此我们既可以在寄存器界面手动设置（看你手速快不快，能不能在复位前设置），也可以通过 *.ini 文件设置该寄存器完成（建议使用该方法，不用拼手速，哈哈）
*.ini 禁用看门狗：
_WWORD (0xE0042004, 0x100); // 注意该代码会将其它位清零。可以采用下面这种方式
//
DEFINE int temp;
temp = _RWORD (0xE0042004); // CSR address
temp |= 0x100;
_WWORD (0xE0042004, temp); 如果上面方法有疑惑，查查鱼鹰分享的历史笔记吧，一定会有所收获的。