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]

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]

Thanks for taking the time to look though the RM. I did see that note a few days ago. I reviewed through code and was sure that bit was enabled by the watchdog MSP init function. I just looked again through the STM32 cube MX generated code and it wasn't. Also, saying "its behavior is not guaranteed" is a bit vague!

Anyways I did find this in the HAL library which clearly explains the situation!

/**
  * @brief  Configure WWDG1 to generate a system reset not only CPU reset(default) when a time-out occurs
  * @param  RCC_WWDGx: WWDGx to be configured
  *         This parameter can be one of the following values:
  *            @arg RCC_WWDG1: WWDG1 generates system reset
  * @note   This bit can be set by software but is cleared by hardware during a system reset
  *
  * @retval None
  */
void HAL_RCCEx_WWDGxSysResetConfig(uint32_t RCC_WWDGx)
{
  assert_param(IS_RCC_SCOPE_WWDG(RCC_WWDGx));
  SET_BIT(RCC->GCR, RCC_WWDGx) ;
}

So if called like:

HAL_RCCEx_WWDGxSysResetConfig(RCC_WWDG1);

It will set the WW1RSC bit.

[ADunc.1]

So, I changed the code to set that bit and I can confirm that the watchdog reset does indeed now cause an external reset. So, the overall problem here was a combination of:

1. Me misinterpreting the WW1RSC bits functionality and possibly making an assumption that the STM32CubeMX generated code would have enabled the watchdog correctly.
2. The reference manual not being completely clear that the WW1RSC bit connects up the system reset to watchdog reset. It actually does say so though, see below.
3. STM32CubeMX not actually setting this bit when it is required to be set.

Code example:

void HAL_WWDG_MspInit(WWDG_HandleTypeDef* hwwdg)
{
  if(hwwdg->Instance==WWDG1)
  {
  /* USER CODE BEGIN WWDG1_MspInit 0 */
	HAL_RCCEx_WWDGxSysResetConfig(RCC_WWDG1);
  /* USER CODE END WWDG1_MspInit 0 */
    /* Peripheral clock enable */
    __HAL_RCC_WWDG1_CLK_ENABLE();
    /* WWDG1 interrupt Init */
    HAL_NVIC_SetPriority(WWDG_IRQn, 0, 0);
    HAL_NVIC_EnableIRQ(WWDG_IRQn);
  /* USER CODE BEGIN WWDG1_MspInit 1 */
 
  /* USER CODE END WWDG1_MspInit 1 */
  }
 
}

Reference manual says WW1RSC bit must be set in a roundabout way:

The bit description for WW1RSC does not actually say what it does.

A picture says a thousand words. This would have made it so much more obvious!

[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.

[ADunc.1]

No worries. I agree its a bit of a mess. I think if the STM32CubeMX code had just set the WW1RSC bit, everything would have been fine. Once you dig deep enough the reference manual for sure says that bit must be enabled and even says why in a roundabout way in an obscure location!

I made the silly mistake of leaving it too late to study the reference manual fully and assumed the STM32CubeMX code had it all under control. I should have known better to trust it!

If ST fix the STM32CubeMX code generation and maybe make it a bit clearer in the reference manual why WW1RSC must be enabled then it will probably never be an issue ...

[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.