# track down the cause of a random reboot

#### bug13

Joined Feb 13, 2012
1,954
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
16,107
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

#### bug13

Joined Feb 13, 2012
1,954
Random reboot of what?
Of a device that I am writing code for. Or do you need to know what actual the device is?

#### bug13

Joined Feb 13, 2012
1,954
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_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
16,107
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.

#### bug13

Joined Feb 13, 2012
1,954
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
8,382
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
16,107
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
16,107
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
8,382
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.

#### bug13

Joined Feb 13, 2012
1,954
Usually you can assign a NMI vector for the watchdog instead of a reset. In that vector log/print trace program execution.
Good idea, will try that.

#### bug13

Joined Feb 13, 2012
1,954
Just to report back, I have a deadlock in my task. Fixed now.

#### BobaMosfet

Joined Jul 1, 2009
1,768
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.

#### bug13

Joined Feb 13, 2012
1,954
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.