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.

[TDK]

Seems like a bug to me. When the WWDG1 generates a "reset", are the WWDG1RSTF+PINRSTF+CPURSTF bits correctly set (per Table 51. Reset source identification (RCC_RSR))?

[ADunc.1]

That's a good thought. I had been checking that the WWDG1RSTF flag was always set which it was, but hadn't thought to associate the PINRST flag. So, I ran the test again, the results are interesting:

Flasg after a software reset (flags cleared before software reset), all as expected:

Flags after a WWDG1 reset:

So, as you can see, the watchdog reset flag is set as expected, but the PINRSTF and CPURSTF flags are not! The PINRSTF seems to make sense and matches the external behavior I see. I don't know much about the CPURSTF flag. The CPU is definitely reset because it boots back from the reset vector.

[Andreas Bolsch]

Your reset circuit is far from being standart: The datasheet (section 7.3.16 or 6.3.16 respectively) suggests 100nF (so in this respect your're right), but *NO* pull-up. The internal pull-up is specified to be between 30k and 50k Ohm. By adding a 10k Ohm pull-up you're shorting the reset pulse considerably ...

Before concluding the chip is buggy it might be a good idea to test again with *NO* external pull-up.

[ADunc.1]

I made no conclusions...

The scope picture of a software reset working correctly shows it can drive the external reset low.

The 10k pullup resistor is standard design practice. The current required to rapidly discharge the 100n cap is significantly higher than that caused by the 10k pullup.​

[Pavel A.]

STM32H753 stepping V or Y?

-- pa

[ADunc.1]

Looks like V?

[Pavel A.]

>  My current workaround is to issue a software reset from the watchdog EWI interrupt.

Or, check the reset reason in startup code. If it was because of WWDG, call NVIC_SystemReset.

-- pa

[waclawek.jan]

Can this be H7-specific?

Has anybody have experience with other STM32 family's WWDG n this regard?

JW

[ADunc.1]

Actually, that's exactly what I do:

  if (__HAL_RCC_GET_FLAG(RCC_FLAG_WWDG1RST) == SET)
  {
    __HAL_RCC_CLEAR_RESET_FLAGS();
    HAL_NVIC_SystemReset();
  }