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.

[ADunc.1]

I know it worked correctly on STM32L4 as the code I am working on was ported from an L4.

[waclawek.jan]

I can't browse the H7 RM right now, but I'd read the WWDG chapter to find a "enable reset output" flag, and then search in test of the document for WWDG.

I would not be surprised to find a related option bit.

JW

[ADunc.1]

There are not many options to control this watchdog, it is pretty basic. A counter, a window value, a prescaler, an early wakeup flag and an activation bit.

[waclawek.jan]

I mean a bit in option bytes, i.e. those stored in the system FLASH.

JW

[ADunc.1]

There are no WWDG option related bits according to a search. There is nothing in the reference manual suggesting there is anything to disconnect the reset output of the watchdog circuit from the reset circuitry. There is obviously something in there that disconnects it, but whether its an option or not...

These sections of the manual suggest WWDG reset causes a direct pin reset of the micro:

[waclawek.jan]

Sounds much like a genuine silicon bug, then...

@Amel NASRI​ , can you please have a look at it? [EDIT] please have a look at the posts below [/EDIT]

Thanks,

JW

PS There's nothing related in errata already, I presume?

[ADunc.1]

Thanks for inviting ST to look. I searched errata for wwdg, watchdog, reset etc but found nothing...

[waclawek.jan]

I managed to get to the 'H7 RM now:

JW

[waclawek.jan]

@Amel NASRI​ ,

As shown by this thread, this is a nasty gotcha, caused primarily by the "IP chapters in RM don't describe related features beyond their boundaries, even if crucial to their working" policy.

I'd suggest to add references to WW1RSC to each and every place where wwdg1_out_rst is mentioned, namely:

Figure 39. RCC Block diagram - showing a gate controlled by this bit

narrative in 7.4.2 System reset detailing effect of WW1RSC

Figure 40. System reset circuit - showing a gate controlled by this bit

Table 50. Reset distribution summary - pointing out that it's *not* the same effect as pwr_bor_rst, unless WW1RSC is set

Table 51. Reset source identification (RCC_RSR) - detailing behaviour at *both* WW1RSC settings

There's also a mention of wwdg1_out_rst in Table 93. EXTI wakeup inputs - this is entirely unclear to me, how a reset-causing signal would cause and EXTI/wakeup too; but maybe that's also related to WW1RSC - a detailed description would be nice.

A remark, that signals change their names through instatiation, e.g. wwdg_out_rst->wwdg1_out_rst, would be beneficial in all IP chapters, facilitating textual search through the RM. This goes together with an overview of instatiations in the intro of all IP chapters - there are already such, but not in all IP chapters. This case shows, that even where there's only one instantiation (WWDG1), such subchapter is needed.

And, of course, a reference to WW1RSC would be great in the WWDG chapter, but I would be very surprised if that would ever happen, given the policy I've mentioned above.

[EDIT] please see also subsequent post [/EDIT]

JW

[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