Watchdog Timer to reset the processor.

Hello Gustavo,

Can you share your code?

Regards
Amit

Gustavo, Also define what you mean by doesn't work.

Robert

Sorry ! I tried to use this code. But I´m not sure if its ok.

I suposse, the watchdog timer will issue a reset to the processor
after a second timeout condition.

void watchdog(void)
{
/* Enable the peripherals used by this example. */
SysCtlPeripheralEnable(SYSCTL_PERIPH_WDOG0);

/* Set the period of the watchdog timer. */
WatchdogReloadSet(WATCHDOG0_BASE, SysCtlClockGet());

/* Enable reset generation from the watchdog timer. */
WatchdogResetEnable(WATCHDOG0_BASE);

/* Enable the watchdog timer. */
WatchdogEnable(WATCHDOG0_BASE);
}

int main(void)
{
watchdog();

WatchdogLock(WATCHDOG0_BASE);

while(1)
{



// Another task in general


WatchdogIntClear(WATCHDOG0_BASE);
}
}

Gustavo Galindo said:

I suposse, the watchdog timer will issue a reset to the processor
after a second timeout condition.

Gustavo Galindo said:

while(1)
{



// Another task in general


WatchdogIntClear(WATCHDOG0_BASE);
}

What are you doing that would cause a timeout?

Robert

Hello Gustavo

Which TM4C device are you using?

Regards
Amit

Hi Amit, 

I'm using the TM4C123G.  The  main reason why I want set the watchdog timer is because I'm setting  a UART communication with other devices so it could be lost and the processor should be reset.  I think, may be the instruction WatchdogReloadSet(WATCHDOG0_BASE, 250000000 ); should be in the infinite loop ( while(1){}) in order to reload the time to the timer. 

Thank you again.

Hello Gustavo,

So with this approach how will the processor come to know that UART communication is lost? There must be a method for the CPU to know that and it knows that then SysCtlReset is sufficient to reset the device and does not require the WatchDog. The WatchDog is of importance when the CPU cannot execute due to a unrecoverable fault.

Regards
Amit

Gustavo Galindo said:

The  main reason why I want set the watchdog timer is because I'm setting  a UART communication with other devices so it could be lost and the processor should be reset.

That appears a little over-enthusiastic.  Would it not make more sense to simple reset the communications protocol?

Watchdogs are meant as a method to recover when the processors is not executing as required, not as a timeout technique.

And you still haven't explained how, in your setup, the processor will ever stop feeding the watchdog.

Robert

Hello Robert,

Details elude the post and more importantly implementation document....

Regards
Amit

Gustavo,

Here is the code I use for controlling the watchdog. It is in C++, but you can easily convert to C. The countdownValue variable is a member variable of the class, but you can just make it a static variable for C purposes.

I call the initialize function during startup, the enable function when I want the watchdog to start doing its thing, and the retrigger function within my main loop.

/// Time (in ms) after which watchdog will time out and cause a reset if it
/// has not been retriggered.
static const U32 WATCHDOG_TIMEOUT_PERIOD_MS = 250U;

/// Number of milliseconds in one second
static const U32 MS_PER_SECOND = 1000U;


void Watchdog::initialize(void)
{
// enable the watchdog peripheral
SysCtlPeripheralEnable(SYSCTL_PERIPH_WDOG0);

// determine the required countdown value
U32 sysClkFreq = BSP_SysClkFreqGet(); // YOU MAY NEED TO DETERMINE CLOCK FREQ DIFFERENTLY FOR YOUR SYSTEM!
countdownValue = (sysClkFreq / MS_PER_SECOND) * WATCHDOG_TIMEOUT_PERIOD_MS;
}

void Watchdog::enable(void)
{
// unlock the watchdog registers, if necessary
if(WatchdogLockState(WATCHDOG0_BASE))
{
WatchdogUnlock(WATCHDOG0_BASE);
}

// initialize the watchdog with the required countdown value
WatchdogReloadSet(WATCHDOG0_BASE, countdownValue);

// configure watchdog timer to stop when debugger halts processor
WatchdogStallEnable(WATCHDOG0_BASE);

// enable the watchdog to generate a reset when it times out. doing this
// also starts the watchdog (see section 17.3 of data sheet)
WatchdogResetEnable(WATCHDOG0_BASE);

// lock the watchdog registers to prevent them from accidentally getting
// changed by runaway code
WatchdogLock(WATCHDOG0_BASE);
}

void Watchdog::retrigger(void)
{
// unlock the watchdog registers, if necessary
if(WatchdogLockState(WATCHDOG0_BASE))
{
WatchdogUnlock(WATCHDOG0_BASE);
}

// load the watchdog with the required countdown value
WatchdogReloadSet(WATCHDOG0_BASE, countdownValue);

// lock the watchdog registers to prevent them from accidentally getting
// changed by runaway code
WatchdogLock(WATCHDOG0_BASE);
}

Hope this helps,

Dave

Thanks Dave,

Has it performed its task correctly ? and do you know how can I use the instruction SysCtlReset() , I'am setting a UART communication, I think, by poling. So if the communication is lost I have to restart the process. I send to the other system a command and when that gets the command answer with a string of bytes ( I do this action 8 times), so a problem in the communication can ocurred.

Thanks

Hi, Gustavo,

Yes, the watchdog code works fine. I tested it by adding a flag that can turn off retriggering of the watchdog, and when I set that flag (via a serial command sent over the USB)  the system times out and resets.

As far as SysCtlReset() goes, I am not quite sure what you are asking. If you want to reset the micro and all the peripherals you can just call that function. Presumably you would call it from whatever place you have determined that your communications link has locked up.

Regards,

Dave

Hello Gustavo,

IMHO, In this case it would be the watchdog interrupt handler calling the SysCtlReset. In the Watchdog interrupt handler there must be a method for the application to determine an com link hang up, either bytes not uodated, ack not received.

Regards
Amit

Hello Gustavao,

Since you are using a Com Link there must be some method for Command and Response. The time duration is decided by the time from Command Start to Response end and it can vary if the other side of the link is loaded or not. If it is loaded it may take time. Hence the observation of time is not a suggested method as it may be between MIN and MAX and MAX is what you need to determine.

One possible method is to use a timer to count the number of clocks from Command to Response during a Learning Phase to get a ball park of the time. Then use this as a count for the WatchDog such that on first expiry or Watch Dog interrupt you reload the WatchDog to see if the response is delayed. If response comes then adjust the new Timeout value. if not then declare the link broken, Of cousre you need to keep an application maximum (APP MAX) such that if the MAX goes above APP MAX then it is an extreme degraded performance.

Regards
Amit

Umm, you're trying to use the watchdog to detect a communications timeout? Do I understand that correctly?

That's a bit like using a sledgehammer to set a tack.

Robert

Robert is quite right. Normally the watchdog timer is used to protect against code getting stuck in an infinite loop, or executing from locations it is not supposed to ("runaway code"). By retriggering the watchdog in non-interrupt code (normally in your main loop) you can address these situations.

But for communication timeouts you really should be using a different mechanism. Either use a general purpose timer, or, if you have a system tick, bail out after a certain number of ticks. The timeout should be well greater than the worst-case expected time for the other side to respond. If this timeout occurs, call SysCtlReset() if you think you need to reset the whole micro, or preferably take a less radical approach and just reset the comm link.

Regards,

Dave