Senior

Question

STM32H7 watchdog does not correctly reset. Example attached

Forum|Forum|6 years ago
May 4, 2020
16 replies
14666 views

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.

WDogTest.zip

This topic has been closed for replies.

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))?

"If you feel a post has answered your question, please click ""Accept as Solution""."

ADunc.1Author

Senior

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

Lead III

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.1Author

Senior

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.1Author

Senior

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

ADunc.1Author

Senior

Actually, that's exactly what I do:

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

waclawek.jan

Super User

Can this be H7-specific?

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

JW

ADunc.1Author

Senior

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

waclawek.jan

Super User

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.1Author

Senior

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

Super User

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

JW

ADunc.1Author

Senior

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

Super User

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.1Author

Senior

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

waclawek.jan

Super User

I managed to get to the 'H7 RM now:

JW

ADunc.1Author

Senior

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.1Author

Senior

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:

Me misinterpreting the WW1RSC bits functionality and possibly making an assumption that the STM32CubeMX generated code would have enabled the watchdog correctly.
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.
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!

waclawek.jan

Super User

@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

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded