[This is a reconstruction of a thread I've started on Mar 26, 2017, but got lost in the two forum software transitions since then.]
Reports in IWDG short period (125 us) problem and STM32F407 : IWDG and erase flash sector indicate that the IWDG does not work as it's (quite simplistically) described in the RM.
To find out the real working of IWDG, I took a DISCO-F4, wrote a snippet which brought out LSI through its connection to TIM5_CH4 onto a pin, wired up a LA and started experimenting.
The following is my interpretation of what I've seen; I don't know what's the real implementation of course so I might have misinterpreted things. I haven't experimented with the debug facility. I haven't used other prescaler than the lowest (i.e. /4) - some of the cycles numbers mentioned below might be dependent on this.
- IWDG_SR.RVU and IWDG_SR.PVU don't get cleared as promised, until the IWDG is started by writing 0xCCCC into IWDG_KR, regardless of whether LSI has been started explicitly previously, or not. RM should say this.
- the IWDG_RLR = 0 setting is unusable. As found by Rubén in the thread linked above (and my experiments confirm), after setting this processor goes unconditionally into reset. Note that table Min/max IWDG timeout period at 32 kHz (LSI) explicitly deals with RL[11:0]=0x000; I wonder how was this established.
- after having kicked the dog by writing 0xAAAA into IWDG_KR, there is a "guard time" until further kicks are ignored (probably resulting from the different clock domain synchronization mechanism). My finding was, that that "guard time" is 3 LSI cycles. The practical consequence is, that for the lowest possible setting of IWDG_RLR = 1 (i.e. reset time = 1 prescaler cycle = 4 LSI cycles = typ.125us), the dog has to be kicked within a relatively narrow window between 3rd and 4th LSI cycle. Normally, programs are not supposed to be synchronized to LSI for watchdogging purposes, thus the real consequence is that the dog has to be kicked faster than LSI runs (i.e. faster than once in 21us worst case), four times faster than what would follow from the description. This effect is less pronounced with longer watchdog times of course - e.g. with IWDG_RLR=4 (and still the fastest prescaler) we have to kick the dog once in 13 rather once in 16 LSI cycles.
- it appears that the same "guard time" applies after writing to IWDG_RLR, i.e. the dog cannot be kicked (kicks are ignored) until 3 LSI cycles elapsed after IWDG_RLR has been changed. The practical consequence is, that the watchdog timer itself still runs with the old timeout after IWDG_RLR change until gets kicked, but can't get kicked until the "guard time" elapses, so the program cannot rely on the new setting if only attempting a kick immediately after the IWDG_RLR has been written. The workaround given in second thread linked above uses the fact that the "guard time" is shorter than the time needed to clear flags in IWDG_SR (RM says 5 LSI cycles, my findings were 6 LSI cycles but maybe I am misinterpreting something again).
- after the timeout given by IWDG_RLR expires, it takes further 4 LSI cycles until the actual reset occurs. So, with the shortest setting IWDG_RLR = 1, it takes worst case 8 LSI cycles (470us worst case) until chip is reset after a software mishap which would stop the dog being kicked.
As I've said, this is just a guess how things might work, I don't see the innards of the chip.
ST, please comment.
Thanks,
Jan Waclawek
