IWDG findings

[waclawek.jan]

[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

[STOne-32]

Dear @waclawek.jan ,

Many thanks for the detailed experiments, Once back to office next week , we will feedback with detailed answers and actions .

have a great Sunday !

STOne-32

[STOne-32]

Dear @waclawek.jan ,

Greetings and How are you doing today ?  After a long and deep investigation with our experts and design teams that took about 5 days including some public holidays. We confirm all of the findings on IWDG and our action plan is on-going to update and communicate via our official documentation :

• 1 & 2 will be covered by Reference Manual update and clarification of behavior.
• 3, 4 and 5 will be covered by adding a limitation on IWD in Errata to explain how to workaround the non wanted behavior .

thank You very much again for your time and patience , if you need early drafts once we approve them internally @Sarra.S  can help .

have a great weekend and many many thanks for the valuable contribution .

Ciao 

STOne-32

[waclawek.jan]

Hi @STOne-32 ,

Thanks for letting us know.

> if you need early drafts

Thanks, I don't. I don't use the IWDG, in fact, this was my only "physical" encounter with watchdogs as such so far (although I've written about them in the distant past).

However, what I would very much like to see is an Application Note. I know that means another 5 or more days of work, including FAEs, but I believe it's time and effor well spent. In such AN, I'd like to see a general overview of the topic, including discussion of merits and drawbacks (as they are!) of using WD as such, legislative requirements for its usage; discussion of various forms of WD from hardware single-shots through clocked ones up to complex things like WD-refresh-over-internet; overview of WD implementations in STM32 families; intimate details and relationships such as LSI-autostart-which-does-not; techniques to use IWDG in software and common pitfalls, errors and misconceptions.  (Oh, maybe that's not one AN. You may have heard of my "dozens of appnotes per peripheral" mantra...)

JW

[waclawek.jan]

Hi @STOne-32 ,

I've checked the new RM0090 (rev.20, 07-Feb-2024) and ES0182 (Rev 15, 12-Feb-2024) and I don't see any change in IWDG descriptions there.

JW

[STOne-32]

Hi @waclawek.jan ,

Indeed, as the change is impacting many series  the updates relative to IWDG are not yet processed in this RM0090 . Let me check the status and back to you @Sarra.S .

thanks for the patience.

STOne-32