2020-05-04 03:43 PM
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.
2020-09-25 03:41 AM
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
2020-10-05 01:39 PM
@Khouloud ZEMMELI . Thanks for letting me know this has been fixed. Unfortunately it does not generate the correct code.
I happened to b regenerating by code today and noticed it would not compile. Below shows the code. You can see where I had added the line in the user code section and where the newly generated code has correctly added the line into the auto generated section however, there is an extra () that shouldn't be there...
void HAL_WWDG_MspInit(WWDG_HandleTypeDef* wwdgHandle)
{
if(wwdgHandle->Instance==WWDG1)
{
/* USER CODE BEGIN WWDG1_MspInit 0 */
// This but must be set to make sure the WWDG does a full system reset, not just a CPU reset. This is not clearly documented in the
// reference manual and missed by STCubeMX code generation. Without this bit set, the watchdog causes a CPU reset, but the sytem, peripherals
// and the watchdog itself are not reset!
// Refer: https://community.st.com/s/question/0D53W000006EROWSA4/stm32h7-watchdog-does-not-correctly-reset-example-attached?t=1588755060845
HAL_RCCEx_WWDGxSysResetConfig(RCC_WWDG1);
/* USER CODE END WWDG1_MspInit 0 */
/* WWDG1 clock enable */
HAL_RCCEx_WWDGxSysResetConfig(RCC_WWDG1)();
__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 */
}
}
2020-11-17 02:38 AM
Hi @Community member ,
Sorry to come back late to provide an answer for your feedback.
Checking on my side with STM32CubeMX 6.0.1, there is no such compilation issue.
If you still have the same issue on your side, please share your .ioc file for check.
-Amel
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2020-11-17 11:59 AM
@Amel NASRI , I still have this issue every time I generate code. An extra pair of brackets is appended to the HAL_RCCEx_WWDGxSysResetConfig(RCC_WWDG1)(); line. I am currently using latest 6.0.1 STM32CubeMx. If you send me an email address, I will send our configuration file with the issue.
2021-09-06 04:39 AM
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.