cancel
Showing results for 
Search instead for 
Did you mean: 

Independent Watchdog, Instruction before reset

George.P
Associate III
Posted on April 18, 2015 at 10:08

Hello,

I'm running an Cube project with FreeRTOS, with iWDT enabled, on STM32L1 and debugging on IAR.

iWDT is being cleared in its own thread, with the same priority as the other threads.

No thread is a blocking thread.

The iWDT resets the MCU after a random duration and I'm not sure how to to debug the situation, as I don't know what was the instruction or loop where the application froze and caused the reset.

I already use a UART to output some data communication, so I know that the other threads do not freeze.

Is there a way to find out what was the instruction before the iWDT reset jump?

Thanks!

George
4 REPLIES 4
jpeacock
Associate II
Posted on April 18, 2015 at 23:00

The IWDT is a processor reset so there's no way to trap it and it's not an interrupt, no data on the stack.  In any case, the last instruction isn't likely to tell you very much in a multi-tasking system.  You can save the last task number in FreeRTOS when changing task context, at some specific location like an RTC/backup data register, which will tell you roughly where you are, but I doubt that will help if you are sure a task isn't stuck in a loop.

The real question is why your routine to clear the IWDT isn't working.  The watchdog is doing exactly what it's designed for, telling you there's something blocking the IDWT reset for too long.  How is this reset implemented?  Is it in a task that's at a low priority and not getting enough CPU resource?  Is it in an interrupt that's not being triggered?  Try trimming down your tasks to the minimum to find the point where the IWDT starts to work properly.  And are you sure the instruction sequence to clear the IWDT is right?

I use the IWDT to verify the RTC is working.  Once a second the RTC interrupt unblocks the highest priority system monitor task which resets the IWDT after a sanity check.  That ensures my time of day time base is working plus I get a fast hardware failure if the RTC crystal stops working.  I use the Windowed WWDT to ensure the SysTick timer is working and the SysTick interrupt falls within the expected 1ms window.  That guarantees the RTOS time base is working.

  Jack Peacock
Posted on April 19, 2015 at 00:00

You could save the registers as seen by ResetHandler, and inspect them later.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
George.P
Associate III
Posted on April 20, 2015 at 07:13

Hello Jack and Clive,

Thank you for the comments, they gave me some intuition on how to proceed debugging this.

I'll store somewhere what the last task switch was, some information about the stack and add some counters of my own on the interthread queues. Could be a heap failure too.

George
eliast1234
Associate II
Posted on April 20, 2015 at 11:23

George,

You should consider possibility that maybe nothing is being frozen and some tasks need a little longer than you anticipated. Just increase the IWDG period to maximum possible value.

eliast