一个关于STM32 WWDG应用的相关话题

    “刚接触使用WWDG,尝试通过定时器定时喂狗。使用TIMER2并开启溢出中断，在中断里置位喂狗提醒标志。在主函数里监测提醒标志，若监测到喂狗标志置位，则进行喂狗操作并清零喂狗标志。可是发现每当打开WWDG后，感觉就进不去定时中断了，总是喂狗失败导致不停复位。如果关闭WWDG，定时中断正常；不用TIMER中断，用while延迟相等时间，也可喂狗成功。想不通为什么WWDG会导致中断失败？”

    在讨论这个问题之前不妨简单看看STM32芯片里的窗口看门狗[WWDG]的一些基本特性和主要控制寄存器。至于STM32看门狗的细节知识建议阅读各系列的参考手册为宜。

    窗口看门狗通常侧重于用来监测因外部干扰或不可预见的逻辑条件造成的应用程序背离正常的运行序列而产生的软件故障。实质上它是个可编程的自由运行7位递减计数器。

        这里主要涉及到3个寄存器。WDG预分频器，WDG控制寄存器[WWDG_CR]，看门狗配置寄存器[WWDG_CFR]。WWDG_CR决定计数器的上限并控制WWDG的启停。WWDG_CFR里的W[6:0]决定喂狗的起始时刻，从该点到0x40形成一个有效喂狗时间窗口，即只有当WDG计数器的值位于这个范围时才可以做喂狗重载操作。否则，如果在计时器的值大于W[6:0]时喂狗或者计数器的值从0x40变为0x3F时都会触发芯片复位。

     好，继续上面的话题。

    现在发帖者觉得因为开启了WWDG从而TIM2不进中断，觉得费解。结合上面WWDG的原理，这个比较容易想到WWDG从初始的T[6:0]一直递减计数到0X3F没有被喂狗而发生了复位。很可能TIM2的定时周期长于或者远长于WWDG从T[6:0]计数到0X3F的时间，这样每次TIM2来不及进中断设置相关标志就被WWDG复位了,这样循环往复。当然，这只是基于问题症状一种可能。

    发帖者就时间参数作了进一步确认，认为定时中断的时间点完全落在喂狗窗口范围内，而且关闭WWDG后，TIM2 周期性更新中断也正常。不使用TIM2，改为别的延时定时方式又能成功喂狗。

    看来问题不是出在那个TIM2定时参数与窗口时间安排上。后来发帖者调试中无意发现每次开启定时器TIM2 都会进一次中断。这一进中断就问题来了，中断里置位了喂狗唤醒标志，退出后主程序见到唤醒标志立即做喂狗操作。显然这下喂早了，WWDG发挥功能了，复位芯片！复位后每次开启定时器时故伎重演，又是提前喂狗，导致复位，周而复始。这样给人以TIM2没进中断，WWDG没有得到及时喂狗而复位的假象。其实呢，喂狗喂的时间不合适而已。

    原因找到了，就比较好解决了。发帖者调整了一下代码，在使能TIMER前先清下相应的UIF位就好。顺便提下，尽量不要在中断里进行喂狗操作。

   至于TIMER配置过程中一使能就产生更新中断问题，有人可能遇到或留意到这点了。有些情况下它可能会对应用带来影响或麻烦。在使能前先做下相关标志的清除也是个不错的办法。再就是注意下配置代码顺序也可以回避。

相关话题链接：

STM32定时器有时一开启就进中断的话题