"); //-->
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 addresstemp |= 0x100;_WWORD (0xE0042004, temp);
如果上面方法有疑惑,查查鱼鹰分享的历史笔记吧,一定会有所收获的。
*博客内容为网友个人发布,仅代表博主个人观点,如有侵权请联系工作人员删除。