track down the cause of a random reboot

Thread Starter

bug13

Joined Feb 13, 2012
2,002
Hi team

Is there any tricks to track down the cause of an random reboot? I can tell from the reset source register that is from a software reset. Most likely from my watch dog timer.

That's all I know for now.
 

Papabravo

Joined Feb 24, 2006
21,159
If the watchdog is involved then the reset can hardly be described as "random". Is there some reason you chose that particular characterization?
Let's begin with the processor. which one are we talking about? You must think we are mind readers.
Now explain how the watchdog timer is enabled and configured.
Lastly, explain how you periodically "kick the dog" to reset the watchdog timeout interval counter/timer.

N.B. The usual reason is looping on a SINGLE condition that will NEVER occur.

There are two corollaries:
  1. Never write a loop in an interrupt service routine
  2. Make sure all loops have more than one exit condition
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
If the watchdog is involved then the reset can hardly be described as "random". Is there some reason you chose that particular characterization?
Let's begin with the processor. which one are we talking about? You must think we are mind readers.
Now explain how the watchdog timer is enabled and configured.
Lastly, explain how you periodically "kick the dog" to reset the watchdog timeout interval counter/timer.

N.B. The usual reason is looping on a SINGLE condition that will NEVER occur.

There are two corollaries:
  1. Never write a loop in an interrupt service routine
  2. Make sure all loops have more than one exit condition
The reboot is not any fixed time interval (that I can tell), to me it's random :)
The processor is CC2640R2F
The WDT is configurated with the provided HAL driver

C:
    Watchdog_Handle wdt;
    wdt = Watchdog_open(CC2640R2_LAUNCHXL_WATCHDOG0, NULL);
    if (wdt == NULL){
        System_printf("WDT init failed\n");
        System_flush();
    }

    if (Watchdog_setReload(wdt, Watchdog_convertMsToTicks(wdt, 2000)) != Watchdog_STATUS_SUCCESS){
        System_printf("WDT set reload failed\n");
        System_flush();
    }
That's how I kick it in the main task (with provided HAL driver):
C:
/* kick the dog */
Watchdog_clear(wdt);
 

Papabravo

Joined Feb 24, 2006
21,159
I never said the reboot interval was periodic. It is the watchdog interval that is periodic. Each time you "kick the dog" you start a new interval of 2000 milliseconds. What that means is that you need to "kick the dog" MORE OFTEN than every 2 seconds. If more than two seconds elapses, because of a non-terminating loop for example, then there will be a watchdog reset related to the non-terminating loop. What happens if you do a System_printf(".") ; each time you "kick the dog"? You should see a series of periods come out on the console, then nothing for 2 seconds, then a watchdog reset. If you see that behavior then you know what to look for.
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
I never said the reboot interval was periodic. It is the watchdog interval that is periodic. Each time you "kick the dog" you start a new interval of 2000 milliseconds. What that means is that you need to "kick the dog" MORE OFTEN than every 2 seconds. If more than two seconds elapses, because of a non-terminating loop for example, then there will be a watchdog reset related to the non-terminating loop. What happens if you do a System_printf(".") ; each time you "kick the dog"? You should see a series of periods come out on the console, then nothing for 2 seconds, then a watchdog reset. If you see that behavior then you know what to look for.
Maybe I do not fully understand your intention here. For my understand, printing a "." can only tell me I have a watch dog reset, and how can I found out the cause of the reset from here?
 

nsaspook

Joined Aug 27, 2009
13,080
Usually you can assign a NMI vector for the watchdog instead of a reset. In that vector log/print trace program execution.
 

Papabravo

Joined Feb 24, 2006
21,159
Regardless of the actual frequency of printing the periods you are looking for a 2 second pause followed by a watchdog reset. If you see ANY other behavior, then the watchdog reset may not be the cause. If you do see that behavior you go looking for a process or piece of code that prevents the "kick the dog" action for a period greater than 2 seconds.
 

Papabravo

Joined Feb 24, 2006
21,159
Usually you can assign a NMI vector for the watchdog instead of a reset. In that vector log/print trace program execution.
A good suggestion, but don't make the mistake of putting the "kick the dog" call INSIDE an interrupt service routine. That is the road to perdition.
 

nsaspook

Joined Aug 27, 2009
13,080
A good suggestion, but don't make the mistake of putting the "kick the dog" call INSIDE an interrupt service routine. That is the road to perdition.
In normal WDT operation you don't but shutting down the WDT system (and maybe other system functions) after a WDT NMI trace activation is usually done if you vector to a debugger or memory dump function in the NMI.
 

BobaMosfet

Joined Jul 1, 2009
2,110
Hi team

Is there any tricks to track down the cause of an random reboot? I can tell from the reset source register that is from a software reset. Most likely from my watch dog timer.

That's all I know for now.
Yes- start simple. No assumptions. Is your reset because of current on the reset pin? Low voltage, insufficient current? Check these first- these can easily cause problems if you are tripping solenoids, or other things.

2nd- flow-chart, flowchart, and walk through your flow-chart with a pencil, testing different things to see where a reset might get caused if you believe it's the watchdog timer.

3rd- turn a pin on at the start of a function, and off- put an LED on it, or watch it with an oscilloscope. That alone can help you isolate.

Divide and conquer- isolation. Simplify if necessary until problem goes away.

Never underestimate the power of pencil and paper to free your mind to work _the problem_, not holding on to esoteric details.
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
Yes- start simple. No assumptions. Is your reset because of current on the reset pin? Low voltage, insufficient current? Check these first- these can easily cause problems if you are tripping solenoids, or other things.

2nd- flow-chart, flowchart, and walk through your flow-chart with a pencil, testing different things to see where a reset might get caused if you believe it's the watchdog timer.

3rd- turn a pin on at the start of a function, and off- put an LED on it, or watch it with an oscilloscope. That alone can help you isolate.

Divide and conquer- isolation. Simplify if necessary until problem goes away.

Never underestimate the power of pencil and paper to free your mind to work _the problem_, not holding on to esoteric details.
Thanks for the suggestions, I will keep these in mind.
 
Top