Debugging resets - Watchdog resetting even after clearing?

[Andres Cao]

Posted on August 29, 2017 at 17:48

Hi!

I have some very sporadic resets that are proving troublesome to debug. I'm using an STM32L083

Based on the RCC_CSR there's an IWDG reset. The IWDG is definitely enabled (total time of 28s) and being cleared often.

Do you know of any reasons I could get an IWDG reset, besides a timeout? The RTC is waking the device from sleep up every 10 seconds and clearing the IWDG.

I thought that a fault handler (Hal Error_Handler or HardFault_Handler) could be triggered, and enabled console messages in case it ends up there. I never read any of those messages.

Is there any other default infinite loop? Any input ideas are welcomed.

Thanks!

[waclawek.jan]

Posted on August 29, 2017 at 18:07

The IWDG is definitely enabled (total time of 28s) and being cleared often.

Do you also change the IWDG period?

JW

[Jaroslav BECKA]

Posted on August 29, 2017 at 18:27

Hello Andres,

make sure that the window option is not enabled. Otherwise if refresh is done too early, the IWDG reset will be triggered.

Another reason could be the infinite loop as you mentioned.

The hard fault exception can be caused by many things.

To find out whether this exception is invoked or not, you can for instance toggle with a GPIO in the infinite loop and check it using oscilloscope.

It is also possible to enable debug in low-power modes. Using breakpoints you should be able to find out if either Error_Handler is called or hard fault exception triggered.

[Andres Cao]

Posted on August 30, 2017 at 13:17

Hi Jan,

No, the IWDG period is set at the beginning and never changed again.

[Andres Cao]

Posted on August 30, 2017 at 13:21

Hi Jaroslav,

I will double check for that, though I don't think so. I will also make a simple 

while(1)

   Clear_Watchdog();

To double check if too fast refreshing can be a cause, just to discard it. 

Do you think putting UART commands on the hardfault handler is a bad idea compared to pin trigger? Because right now I'm just logging the serial port and checking if a reset occured every once in a while. I do this because it's non periodic, it can happen every couple of hours, or sometimes it doesn't happen in a full day.

I'm not using the debugger but will also take a look into it for more possibilities.

[Andres Cao]

Posted on August 30, 2017 at 13:53

Thinking out loud,

Taking a look at the reference manual:

Default window value is 4095, which means disabled. 

I'm using this configuration:

hiwdg.Init.Window = 4095;

hiwdg.Init.Reload = 4095;

Could this be the problem?

Watchdog clear starts the number at 4095 and if it is cleared again it should cause no problem since the reference manual says greater than and this condition would be equal, but who knows.

[Andres Cao]

Posted on September 18, 2017 at 17:29

This doesn't seem to be the problem.

Timed logs tell that the reset is occuring 27s later than the last message, meaning it's the watchdog doing its job properly. 

Any clues as to how to debug this?

[Tesla DeLorean]

Posted on September 18, 2017 at 19:02

>>Any clues as to how to debug this?

Add more telemetry until you understand the code flow.

I always dump state in Hard Fault, if the system is totally broken you learn nothing, but most cases you can pin things down.

Look for spin loops, within your own code, and within the HAL. The latter is packed with them.

Make sure that the SysTick interrupt driving HAL_Tick preempts everything else.

Jan's point originally was that changing the delay would allow you to see if the problem tracked or not.

[Andres Cao]

Posted on September 18, 2017 at 19:26

Thank you Clive, I'll take a look into this.

It appears that the system goes to sleep and never wakes up again. The system wakes up every 10, and the IWDG is 27 seconds. The IWDG is doing it's job correctly, I'll also check the wakeup routine to see if it might hang there.