MSP430 Watchdog - System hang protection mode

Raj P said:

I am not sure if I need to clear WDT or reload value to WDT to avoid resetting system. 

You don't have access to the counter itself. You can only clear it and when it overflows, it will trigger the PUC (or call the ISR if in counter mode)

Your code has a problem:

Initially, you set the WDT into counter mode (WDTTMSEL). But inside your ISR, you rewrite the WDTCTL register, this time without WDTTMSEL bit. This reverts the WDT into watchdog mode. Next overflow, isntead of calling the ISR, it will trigger a reset.

I guess you misunderstood the concept and mixed two independent usages of the WDT.

If you want the WDT to reset the MSP in case of a crash, you don't enter counter mode and don't need an ISR (and don't set WDTIE bit in IE1). Instead, you must ensure that your code during normal program execution resets the WDT before it overflows.

#define TRIGGER_WDT WDTCTL = WDTPW | WDTCNTCL

[...]
TRIGGER_WDT;
[...]
TRIGGER_WDT;
[...]
while(1) TRIGGER_WDT;

In counter mode (with WDTTMSEL set), the WDT acts like a normal timer with fixed interval size. (no reset, no protection, no need to clear it if you simply want interrupts in a regular interval)

Hi Jens-Michael,

Thank you for explaining WDT working mechanism.

I want to use WDT as protection mechanism  not as interval timer mode rather in watchdog mode, I am still now sure how should I clear WDTCTL (WDTCTL = WDTPW | WDTCNTCL) register continuously when I have put MCU in low power mode while waiting for UART Rx data to exit from low power mode. From the mechanism you described earlier it look like I need to clear WDTCTL register at certain interval before it expires out.

Situation is as follows:

1.  MCU is put into low power mode (LMP3)

2.  when Rx interrupt triggers, system is returned from LMP3 to LMP1 mode.

3. UART data is processed.

4. System is put back into LMP3 mode in while(1)

 where should I clear WDT register in this scenario ??

#include <msp430.h>
int main()

{

/* Stop watchdog timer from timing out during initial start-up. */
WDTCTL = WDTPW | WDTHOLD;

/*Init ports*/

init_ports();

BCSCTL2 = SELM_0 + DIVM_0 + DIVS_0;

if (CALBC1_1MHZ != 0xFF) {
/* Follow recommended flow. First, clear all DCOx and MODx bits. Then
* apply new RSELx values. Finally, apply new DCOx and MODx bit values.
*/
DCOCTL = 0x00;
BCSCTL1 = CALBC1_1MHZ; /* Set DCO to 1MHz */
DCOCTL = CALDCO_1MHZ;
}

BCSCTL1 |= XT2OFF + DIVA_0;

BCSCTL3 = XT2S_0 + LFXT1S_2 + XCAP_1;

/* initialize UART ports */
uartportsinit();

/* Configure WDT*/

WDTCTL = WDTPW + WDTSSEL + WDTIS0;

while(1)

{

__ENTER_LPM3_LOW_POWER_MODE;

check_for_uart_input();

}

 return 0;

}

Appreciate your help.

Raj P said:

 where should I clear WDT register in this scenario ??

Not where. When.
You must ensure that under all circumstances, the WDT will be triggered (reset) in-time.

When you have a waiting loop that may wait longer than the WDT timeout interval: trigger the WDT inside. When you go into LPM, ensure that you wakeup before the WDT expires and trigger it.

In our access point (which uses an ATMega128, but the WDT works the same way), all my ISRs or code blocks have a global counter. Inside my timer ISR, I decrement these counters. When all these counters are still not zero, I trigger the watchdog inside the ISR.
If any code block (actually separate threads) doesn't 'fill up' its counter before it reaches zero, the watchdog will cause a reset. If the ISR stops working, the watchdog will reset the CPU. If the CPU crashes, the watchdog will reset the CPU.

On MSP, I don't use threads (yet). Instead I have just one counter that is filled anywhere where i think the code should come through regularly. With a value that corresponds to the expected maximum execution time until next 'fill-up' in ms. The timer interrupt decrements it and when it reaches zero, the ISR won't trigger the WDT anymore. This allows longer and variable periods between resetting the counter (the old 1x family had a relatively short watchdog timeout. 5x family can now extend the delay significantly).

Note that triggering the WDT must be done the same way (with all the config bits set) as the initial configuration.

In your code, the CPU may stay for an unknown period of time in LPM3. if there is no timer ISR that always wakes the CPU before the WDT expires and triggers the WDT, you'll get a reset. An UART ISR won't suffice, as there might be no data coming in and therefore no ISR execution)
Do you have any ISR that causes the CPU to exit from LPM? If not, your call to check_for_uart_input() will never be reached. (don't set a breakpoint on this line - it will be triggered before LPM is entered).

Jens-Michael Gross said:

When you have a waiting loop that may wait longer than the WDT timeout interval: trigger the WDT inside.

I am sure by saying trigger you actually mean clear, right?

Ilmars said:

I am sure by saying trigger you actually mean clear, right?

'trigger', 'reset' and 'clear' are synonyms regarding WDT. All three are used for the same, depending on whom you talk to (or which document you read).

Note that 'trigger the WDT' of course isn't the same as 'the WDT triggers (a reset)'. Since there is only one bit that must be set, and no access to the counter itself, all three terms are equally right or wrong. (if the WDT were implemented as down-counter, like the prescaler in the timer module, clearing it wouldn't be helpful, while 'reset' may mean both, reset to 0 for an up counter or reset to maximum for a down counter)

I've also seen the term 'kicking the watchdog' (before it barks) :)

Jens-Michael Gross said:

'trigger', 'reset' and 'clear' are synonyms regarding WDT

WDT is timer. If I say "you shall trigger timer" - what's meaning of that? Trigger means "cause action", not "prevent action". What's main purpose of WDT? - To bark!

Jens-Michael Gross said:

Note that 'trigger the WDT' of course isn't the same as 'the WDT triggers (a reset)'.

You can trigger WDT reset by writing incorrect password into it's register.

Ilmars said:

WDT is timer.

This specific implementation of a watchdog, yes. However, other watchdogs are monoflops (which can be considered analog timers). Yet monoflops are triggered, not reset. And they are categorized in retriggerable (not resettable) and non-retriggerable monoflops.

A dead-man switch is also a watchdog, yet it is to be triggered, not reset. even though the trigger may reset the timeout :)
And a dead-man's handle, while serving the same purpose, isn't triggered. It is held, and triggers the action when released.

I agree that nomenclature isn't totally streamlined regarding watchdogs.

However, there i sonly one thing you can regularly do: setting the WDTCNTCL bit, whether you call it clearing the WDT, resetting it or triggering it. (actually, this bit is a trigger, as it triggers the action of resetting the watchdog :) )
(Causing a PUC by writing a wrong password is nothing WDT specific. You can as well do it with the PMM, the FLASH controller, the SVS...)

Now that's going really off-topic...

Jens-Michael Gross said:

Now that's going really off-topic...

It happens every time when you forget where word "agree" is written in your vocabulary :D

Ilmars said:

It happens every time when you forget where word "agree" is written in your vocabulary :D

I always know where it is written in my vocabulary, but I also know why and when to use it :)