Many sample programs for the MSP430 have their first line as:
WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer
Why do they do this?
\$\begingroup\$
\$\endgroup\$
Add a comment
|
2 Answers
\$\begingroup\$
\$\endgroup\$
4
The watchdog timer (WDT) is on by default, it's a useful thing to have in more complex applications, but trips a lot of new people up. They often will not service the WDT in their code or include an interrupt service routine (ISR) to handle the WDT event, so, when their chip keeps resetting they become very frustrated. Additionally, the sample programs are, for the most part, not trying to demonstrate the WDT so it's turned off.
Edit: The watchdog timer could have been named "dead man's switch". Its default behavior is to reset the microcontroller unless the firmware periodically lets it know everything is running fine. This is known as "feeding the dog" or "kicking the dog". This way, if your firmware gets stuck in a loop or otherwise stops operating as expected, the watchdog is not fed and will reset the chip (hopefully to a fresh, working state).
You can also use the WDT as periodic interrupt to perform other tasks, whatever you can imagine. You just have to write the relevant ISR.
-
\$\begingroup\$ +1 thanks, although i and other readers can look it up, it would be nice to know a very brief rationale for why the WDT resets the chip. (don't worry about adding it though, your answer is good enough to accept as it is (after waiting a few more hours for other possible answers)) \$\endgroup\$ Jul 13, 2014 at 7:18
-
\$\begingroup\$ i guess i should have mentioned in the question that i am an absolute newbie who also has no clue what is the watchdog timer is :) \$\endgroup\$ Jul 13, 2014 at 7:19
-
2\$\begingroup\$ @necromancer Ah, no worries, I've added the relevant information. \$\endgroup\$– SamuelJul 13, 2014 at 7:35
-
2\$\begingroup\$ Samuel- in almost all cases you should NOT use an ISR to reset a WDT. It's almost always the wrong thing to do. The interrupts can merrily continue while other parts of the program are off in la-la land. It's occasionally possible/necessary (with communication between the ISR and other parts of the firmware that effectively sets a second level of WDT) but should not be suggested to a newbie as a first approach. \$\endgroup\$ Jul 13, 2014 at 12:42
\$\begingroup\$
\$\endgroup\$
1
In addition to Samuel's point about people accidentally tripping the WDT, there's another important reason why it should be disabled initially.
Even if your application is normally capable of resetting the timer correctly, it may not be able to do so during the initialisation code, for two reasons:
- Initialsation might take longer than a single WDT tick, but require interrupts to be disabled. This means that if you rely on, say, a timer ISR to reset the timer, you could get into an infinite boot loop.
- You don't necessarily know the state of the timer register on all MCUs (ie, the next tick could be much sooner than expected, as the register might not start at 0).
As a result, it's good practice to disable the WDT as the very first thing you do, even if you never enabled it.
If you do want to use it, you can re-enable it immediately before turning on interrupts, as the last step of your initilsation code.
-
\$\begingroup\$ +1 thank you for adding to the answer. i discovered that you can disable it before initialisation using
int _system_pre_init(void)function, which executes beforemain\$\endgroup\$ Jul 13, 2014 at 12:58