Watchdog timer operation in MSP430

The WDT in MSP430 is not smart enough to watch for faults. It can only do the following:

You can tell it to hold counting and do nothing.
You have a choice of clock sources.
You have a choice among a few counter sizes.
You can clear the counter so it counts from 0 again.
You can tell it to reset the system or generate an interrupt when the counter overflows.

It can be used to catch some kind of program run-away. Namely you normally clear the counter once in a while so that if the program run the way you expect, the counter will not ever overflow. However, if the program gets stuck somewhere or runs wild, (hopefully) it will not get a chance to clear the counter before it overflows, and thus cause a system reset.

When you use: "WDTCTL = WDTPW;", you are telling it to use SMCKL and continue counting (from where it was put in HOLD), and generates a system reset when the counter overflows (unless you clear the counter before that happens).

"WDTCTL = WDTPW+WDTCNTCL;" will do the same plus clear the counter to 0 instead of continue from where is was. Sleep or not sleep, hold or not hold, this is what you need to do periodically before it overflows. (People call this "kick the dog".

thanks old_cow,

in all cases i dont want system reset because that will affect scheduling in the project.

how can i prevent that.

does WDTCTL = WDTPW + WDTCNTCL creates system reset??

The "normal" usage is, you do "WDTCTL = WDTPW+WDTCNTCL" periodically so that it will NOT get a chance to overflow and thus will NOT cause reset. The purpose is that in case your code get stuck unexpectedly, chances are that your "WDTCTL = WDTPW+WSTCNCL" statement will not be executed and WDT will reset the system and save the day. It is like a safety-net, you do not intend to land into that net, but just in case you fall, it can keep you alive. If you do not want this safety-net, then you can hold the WDT and not to use it. Or, you can used it as a Timer and generate an interrupt when it overflows.

I don't know your program code, but from the description I can imagine the following:

Your program enters an endless loop, in which you clear the WDT periodically.
You deactivate the WDT before entering LPM.

If the two intermix, it might be that you're clear the WDT between two sleep phases (reactivating it) and then do not hold it again before fallign asleep again. Then it might trigger.

Alternatively the reset may have nothign to do with the WDT (you should check the status bits whether the reset was WDT-caused.)

You didn't mention your actual MSP device. There are 270 different, and depending on the family, the WDT may act very differently.The base funcitonality is the same, but timings, configuration options or failsafe operations vary across different families.

Jens-michael,

Sorry for late reply.  i understood wht you saying. my code is exactly working as per your saying.

I am sure that watchdog timer is doing reset, because i havent seen that problem b4.

b4 i uesd to have " hold WDT " in my forever loop. that is i was not activating it forever , i disabled that foreever.

but recently, i put WDT running which created problem.

I am new to this micro its MSP430F2132.  is it essential to run WDT in a code instead keep it disabling.

if not can you suggest a way to avoid such reset.

The WDT shall restart your device if it does not respond anymore in a defined manner. If you disable the WDT, it cannot perform this task, obviously.
So what is if the MSP crashes during sleep? The WDT is halted and it will never wake up again.
Or if the crystal fails that triggers the periodically wakeup. Then it will stay dormant without noticing.

You can set the WDT to its longest period and configure the device that it wakes up in time, triggers the WDT and goes to sleep again. This is a minor power issue but greatly increases the operational safety.

Of course if the fault condition is nothing your code can handle (such as an oscillator fault if you cannot switch to uncalibrated DCO mode if this condition persists), then it makes no difference whether there is a WDT or not. Switch it off then or use it as an additional cheap timer.

On my own applications, power consumption isn't an issue (we measure industrial per consumption  when the devices is attached to a 92kW/400A power line, there is no need for sleep modes). But if the device ha sa problem, it has to reset and if the problem persists, it has to show this (blinking LED or whatever) instead of dying silently. The hardware is designed that the LEDs are on at device reset and must be actively switched off. So unless the power supply fails (whcih will switch the power LED off) , you'll always see that something is wrong  even if the processor is in eternal reset.

Anyway, if the reset comes from the wdt, then you're triggering the wdt not fast enough. Why this happens, I don't know without looking at the code. What do you do in your endless loop?  When do you reset (and therefore enable) the WDT and what happens before you disable it again and go into sleep? Possibly there is something wrong in the order of events.

Example: the sequence

hold WDT
enter LPM
reset WDT

will have a side-effect: when the system goes into LPM, the 'reset WDT' instruction is already fetched (instruction pipelining). At the next interrupt it will be executed before the interrupt takes place. (entering LPM has just disabled MCLK and frozen the CPU, but not stopped the ongoing program execution flow) If the ISR then returns to LPM (it was a different one than the one intended to wakeup the cpu main loop), the watchdog is enabled but your main loop won't continue. And then it will eventually expire...

this is what my application does,

in forever loop

{

  WDTCTL = WDTPW + WDTCNTCL;

check for AC power;

if present

{ WDTCTL = WDTPW ;

do some more checking

}

if absent

{

Do some work

}

now in some other loop

if(power is absent and flag=1)

{WDTCTL = WDTPW + WDTHOLD;

go to LPM}

now in LPM only interrupt active

so i check for AC power in timer interrupt

if AC present

{  COME OUT OF LPM;

   }

AS in forever i am activating WDT again if i see power after coming out of LPM WDT gets activated.

let me know you find any fault in the sequence.

{

  WDTCTL = WDTPW + WDTCNTCL; // WDT CNT is cleared and it is counting from 0

check for AC power; // WDT CNT is counting

if present

{ WDTCTL = WDTPW ; // This has no effect, but it does not hurt either

do some more checking // WDT CNT is counting

}

if absent // WDT CNT is counting

{

Do some work // WDT CNT is counting

}

now in some other loop // WDT CNT is counting

if(power is absent and flag=1) // WDT CNT is counting

{WDTCTL = WDTPW + WDTHOLD; // WDT CNT is not counting now

go to LPM}

now in LPM only interrupt active

so i check for AC power in timer interrupt

if AC present

{  COME OUT OF LPM;

   }

.............

In all the above lines where I added "// WDT CNT is counting", if the WDT CNT overflows, it will generate a reset.

If your "checking..", "do some more checking", "do some work", "now in some other loop", etc. takes too many clocks to finish then the WDT CNT will overflow.

To prevent that, you need to insert more "WDTCTL = WDTPW + WDTCTNCL;" between those lines to make sure that the WDT CNT does not overflow.

thanks old cow for your information.

is there any way we can debug and see at what time it overflows.

also i will put WDTCTL = WDTPW + WDTCTNCL in al my rest of the funtions. and see wht happens

thanks for your reply again.

Seems that you are using an 8MHz clock on a WDT with 15-bit CNT, thus it takes:

(2^15) / (8 MHz) = 32768 / (8 MHz) = 4096 microsecond for the WDT to overflow after you cleared it.

As long as you clear it more often then every 4096 microsecond (or less then 32768 clocks apart), you will NOT get a reset.

The real question is, how many microseconds (or how many clocks) does it take the CPU to execute your "do something".

old_cow_yellow said:

(2^15) / (8 MHz) = 32768 / (8 MHz) = 4096 microsecond for the WDT to overflow after you cleared it.
As long as you clear it more often then every 4096 microsecond (or less then 32768 clocks apart), you will NOT get a reset.

On 1.x series, the WDT can be configured to be clocked by either SMCLK or ACLK. If one of them is unused in the software or used with less than maximum speed (e.g. 1MHz or 32768kHz), then if hte WDT is clocked from there, it will expire MUCH slower. (for a 32kHz clock, the maximum delay would be 1s and ~33ms for 1mHz).

Later WDT versions (e.g. 5x series)  have a 31 bit counter and allow delays up to 18hrs. And also more lock options, such as the internal 32kHz clock or the power-saving VLO clock (with ~10kHz). The default value, however, is still 32768 pulses from SMCLK.

Thanks Old_cow  and jens-michael,

I am using 8Mhz clk

BCSCTL1= CALBC1_8MHZ;

DCOCTL = CALDCO_8MHZ;

so upto my knowledge WDT overflows in 4096micro sec. which causes reset in the system. 

The best option as suggested by jens-michael. i shud use

WDTCTL = WDTPW + WDTCNTCL;

very often in my code almost in every loop. If you find any other way please let me know. 

On the 2xxx series, ACLK is always routed from XT1, so if oyu don't have an XT1 crystal, ACLK is useless. (on 1x and 5x series, ACLK can be sourced from DCO too)

You can set your SMCLK to 1MHz with

BCSCTL2 |= DIVS0|DIVS1;

This will slow down the SMCLOCK which is clocking the WDT from 8 to 1MHz and therefore raise the WDT timeout time from 4 to 32 ms.

Of course this is only an option if you don't need SMCLK to be faster.

Personally, I find 1MHz a really good time base for any timing application. Except if you want to use UART or SPI with high baudrates.

At this point i cant change my clock freq. which is set to 8 MHZ.

although, i am using SMCK with divided by 8 option for timer intrrupt option.

TA0CTL = TASSEL_2 + MC_2 + TAIE;

is there any other options i can use instead changing clk speed

I fear not.
At least not in software. You could add a crystal to XT1 and clock ACLK form there and then clock WDT from ACLK. Which will disable WDT if the crystal fails.

On some 2x devices, there is a VLO clock (10-20kHz) and ACLK can be clocked from there LFXT1Sx bits in BCSCTL3). If you then switch the WDT to use ACLK, you can set the WDT timeout to 1-50s (depending on the ACLK input divider and the actual VLO frequency)

But if you're using SMCLK/8 for the timer (do you? your code line doesn't show. ID0/ID1 should be set) and don't need SMCLK for something else, you can clock SMCLK down to 1/8 (DIVSx bits in BCSCTL2) and use it without divider in the timer.

jens,

i am sorry i still use 8MHZ in my timer interrupt. which i cant change. because my board is communicating to another interface in which i need 8 Mhz clk speed.

as Lichen Wang  suggested to put more clear WDT commands in between the timer events or other loops i can do that and see wht happens.

Thanks for reply and your time.

The flip side is, if you sprinkle "WDTCTL = WDTPW + WDTCNTCL;" everywhere in you code, you invite the risk doing it even when your code runs wild. The good news is, it will not reset the system.

since, i do not have any other option. i can not change clk speed.

i have to follow the option. lets see wht is does.

i wil keep posted you my progress

again thanks everybody for help.

abhishek Sabnis said:

The best option as suggested by jens-michael. i shud use

WDTCTL = WDTPW + WDTCNTCL;

very often in my code almost in every loop. If you find any other way please let me know. 

There is anotherway of WDT usage which I use on my projects.

It is a good 'workaround' if you have a longer main loop time than the maximum WDT period.

It requires, however, the existence of a timer ISR that is called fast enough.

In my code, I have a global variable.
In the timer ISR (which is executed every ms in my projects, the 'heartbeat'), I check whetehr this variable has reached a certain value (project specific setting). If not, the variable is incremented and teh WDT is triggered. If the value has been reached, the WDT is no longer triggered.

In the main loop, the software just resets this variable to zero. This extends the WDT timeout from 32ms maximum to 65567ms. Still it needs to be triggered every 32ms, but this is in an ISR and not in the code, which may take much longer for every loop.

If properly written (in the flash write function), this even survives a temporary lockdown due to Flash erasing.