STM32H7 watchdog does not correctly reset. Example attached

[ADunc.1]

I have been battling an issue for a while where upon a watchdog (WWDG1) timeout, the system was not correctly reset. I was finding that the CPU and NVIC are reset but all the peripherals are not reset after a watchdog reset, they keep their exact register values and even keep operating. A software reset via NVIC_SystemReset works correctly.

The STM32H753 reference manual section 8.4.2 Figure 43 shows that a watchdog reset will cause a transition on the external NRST pin, as will a software reset.

I have prepared an absolute minimal example showing that this is not the case. However, a software reset does for sure generate a transition on the NRST pin. The example lets the watchdog expire (about every 24ms) and reset the CPU. If you scope the NRST pin you will see it does not change state. A break point (or additional pin toggle) will confirm it is indeed doing a watchdog reset. If you uncomment the two lines noted in the example (main.c line 100) so a software reset occurs before watchdog timeout you will see that the NRST pin cycles every ~12 ms as per attached scope picture.

Hardware is custom, but reset circuit is standard. As per schematic picture below. Debugger is genuine ST-Link V2 connected via tag connect cable (no additional components). Although the same behavior is observed with no debugger connected and a full power cycle.

Scope picture of NRST pin with example code (software reset code uncommented). Shows software reset causing a transition on NRST and proves debugger and external circuitry is not holding NRST state.

Scope picture of NRST pin with example code running and watchdog reset occurring repeatedly but NRST pin not changing state.

I am really keen to hear any thoughts or ideas on why this might be happening. It is a bit of a problem when after a reset you expect the peripherals to be in a known state and they are not!

I thought I had a code workaround to call HAL_DeInit to reset all peripherals at startup. But that does not stop the watchdog which keeps running through the reset even though the WDGA bit is clear. So after a WWDG1 reset, the watchdog keeps counting down, then resets again, ang again ... My current workaround is to issue a software reset from the watchdog EWI interrupt.

[waclawek.jan]

Textual search for WWDG1 reveals more funny things, e.g.

which IMO is bogus:

• there's no CPURST bit in RCC_AHB3RSTR (nor in other RCC_xxxxRSTR)
• IMO, CPURST does not *cause* reset of WWDG1 block, but *is caused* by WWDG1 running into reset - again, this will probably depend by WW1RSC

Textual search for CPURST reveals two other apparently related instances, one in CPU reset section of Local resets subchapter, referring to the same nonexisting bit in RCC_AHB3RSTR, and other in the changelog, which says, and I quote:

"Changed CPURST bit to in RCC AHB3 Sleep Clock Register (RCC_AHB3LPENR)."

JW

[TDK]

What a mess!

The RCC_RSR_WWDG1RSTF bit is not touched in the HAL libraries either except in LL_RCC_IsActiveFlag_WWDG1RST to check its status. So probably also a CubeMX bug if you try to use WWDG1.

[ADunc.1]

The WWDG1RSTF flag is not allowed to be written by software. You can read it to see the cause of a reset, but must clear it by setting the RMVF bit. HAL provides the __HAL_RCC_CLEAR_RESET_FLAGS(); macro for this. And if (__HAL_RCC_GET_FLAG(RCC_FLAG_WWDG1RST) == SET) ... for reading.

[TDK]

You are correct of course. I still claim that it's a mess. Thanks for taking the time to write up this post and document your findings.

[Andreas Bolsch]

The reason behind this bit becomes clear when cross-checking RCC_GCR with the H745/H747 RM as these devices are actually the same as the H743 (except that the M4 is disabled on the H743): If it is cleared, only the M7 is to be reset, not the M4.

[waclawek.jan]

Thanks for the explanation.

(btw.it sort of hints that ST expects that the M7 code is more likely be garbage than the M4 code... this IMO is worth a thought too)

While it explains, it does not justify the lack of proper documentation of things. There's a wrong culture of hiding information from the user where ST thinks the user won't need it. It would be perfectly OK for the'H743 RM to explain the reason for that bit exactly as you did. It's not OK not to proofread the manuals, which would reveal the flaw if done properly and carefully. Also it's not OK to refer users to obscure "libraries" and code generators instead of providing clean and concise plain C code examples - which obviously would reveal the problem right away, if tested as appropriate - together with expertly written appnotes detailing the hows and whys.

JW

[Amel NASRI]

Hello,

First action to request the update in STM32CubeMX side is done.

Besides to the "Caution" added in the RM and already mentioned in this discussion, we have the following description for WWDG1EN bit:

This said, it may remain not enough clear and requires farther explanation in RM. I'll raise internally other requests for documentation updates asked by Jan.

-Amel

[ADunc.1]

Thank you for the update. Good to hear STM32CubeMX will be updated.

It would be great if the reference manual just stated what the WW1RSC bit does. E.g. WW1RSC must be enabled before enabling the WWDG1 to ensure a watchdog reset will cause a system reset rather than just a CPU reset. Or link to the WWRSC1 description and have that be clearer about its purpose.

[Khouloud ZEMMELI]

Hello @Community member​ ,

The missed line of code ( HAL_RCCEx_WWDGxSysResetConfig(RCC_WWDG1); ) has been added in the "HAL_WWDG_MspInit(WWDG_HandleTypeDef* hwwdg)" function , fix is done on CubeMX 6.0.0 (available under ST.com)

Best Regards,

Khouloud

[RBerr.2]

I recently encountered the same issue (that the watchdog does a CPU reset not system reset). My cube project includes the following instructions for initialisation already:

HAL_RCCEx_WWDGxSysResetConfig(RCC_WWDG1) 
 
__HAL_RCC_WWDG1_CLK_ENABLE();

However, the problem was that there is no DSB() instruction between them, so the CPU pipelines must have caused the enable to occur before the reset configuration got applied. As soon as I added a DSB() instruction between these two it now works.