How to get more info when watchdog reset occurs

[jeff23]

Posted on August 22, 2017 at 09:43

We are using quite a few stm32 MCUs from 401 to 439, and our program becomes more and more complicated. In order to avoid possible deadloop, we have used watchdog to rescue the system, basically it is working well now. For quality improvement consideration, we want to know more about where watchdog reset occurs. And I've collected following information:

. When a watchdog reset occurs, all RAM data won't be changed.

. The status Reg RCC_CSR has a flag to indicate if it is an (indepent)watchdog reset or not

With this 2 pre-condition, we think it might be possible we save the field status to a reserved section(also RAM area), and later we dump out these data by a certain I/F such as USB,  for static analysis.

 Here comes my question:

1. Is the 2 pre-condition true? ( I made the experiment and it is true in my test but I want to make sure it covers all)

2. Is there any code in your side that has similar implementation?

3. We are using FreeRTOS, the watchdog is feed in maintask, which manages other tasks. Therefore it is possible that maintask is hang but other task is still running,  will that affect the final field(I'm sorry that actually I'm not sure what is the details of this 'field', because in FreeRTOS case, there are many Stack).

Anyway who has similar debugging skill, please also share the way with me, thank you!

#debugging #stm32f4 #wathdog

[Kraal]

Posted on August 22, 2017 at 13:45

Hi !

If you want to be sure that a specific region of RAM is not initialized and if you are using GCC, you can use the NOLOAD attribute in the linker script. See there for an idea on how to do that: 

https://mcuoneclipse.com/2014/04/19/gnu-linker-can-you-not-initialize-my-variable/

[Tesla DeLorean]

Posted on August 22, 2017 at 14:51

RAM is left alone. You also have a 4K NVRAM/BKPRAM area that the linker/loader usually leave alone. Some F4 parts also have the CCM, which you may or may not be using currently.

You could have SysTick record the PC of the instructions it interrupts, recording that in a loop, and then review that post watchdog to see if it is constrained to a tight loop.

You can also output flow and telemetry via a SWV channel or USART to understand what was occuring immediately prior.

Add a break-point in Reset_Handler so you can stop before the C runtime attempts to clear/copy the statics.

[jeff23]

Posted on August 22, 2017 at 16:12

Kraal, I'm using IAR compiler, and it's not so difficult to assign an reserved section in icf file there. Anyway, still thank you for pointing out the way in GCC tool.

[jeff23]

Posted on August 22, 2017 at 16:30

Clive, adding logging in sysTick interrupt is a good idea, however, we are running FreeRTOS, therefore I guess this modification might affect system performance. Now I use the breakpoint in Reset_Handler(file  system_stm32f4xx.c in HAL library), it should be same position you point out, right?   Actually I also plan to add the watchdog reset boot judgement routine here, as said, I assume the call stack when watchdog reset occurs is still there, which should be useful to find out the dead loop position. But I don't know how can the program find that callstack position and which data should be dump out for analysis.

[Tesla DeLorean]

Posted on August 22, 2017 at 16:40

What I had in mind would be rather inconsequential, perhaps not something I'd build into a release build, but certainly something I'd add from the standpoint of understanding what the heck was causing the issue here and decimating debug time.

If you don't have stack depth monitoring add that, and make sure any heap allocations are validated.

Basic telemetry output would help identify any commonality in the flow leading up to the watchdog reset. The reset handler can identify the watchdog as the cause, and could dump the state data your other routines have accumulated.