• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 153 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR2355: watchdog goes off immediately?

Steve Wenner
Genius 3190 points
Part Number: MSP430FR2355

Hello....

I have the following code in main: (Based on settings I expect watchdog to run for 16 seconds from ACLK....this is a design that has been working for over a year and I am just adding a watchdog to it so hardware is good)

int main(void)
{
    SYSCFG2 |= RTCCKSEL;
    WDTCTL = WDTPW | WDTCNTCL | WDTSSEL__ACLK | WDTIS1 | WDTIS0 | WDTHOLD;   //watchdog 16 second using ACLK, hold state, reset cntr

I then have a pushbutton ISR where I place a breakpoint:

    //activate watchdog
    tempWDCTL = ((WDTCTL | WDTCNTCL) & 0x00FF);
    tempWDCTL &= ~WDTHOLD;
    WDTCTL = WDTPW | tempWDCTL;
    P1IE &= ~0xFE;

A breakpoint on P1IE reveals WDTCTL = 0x6923 which looks correct to me.  Can someone tell me what I am doing incorrectly?

Thanks

Steve 

  • 0
    Guru 19825 points

    The usual way to do things is to put the dog in hold at the start of main() (or earlier if need be) and then set it as desired later. Then reset the counter periodically. You don't show the periodic reset.

    If you really are clearing WDTHOLD in an ISR, that is wrong.

    Usual link to an article on watchdogs: www.ganssle.com/watchdogs.pdf

  • 0 in reply to David Schultz
    Genius 3190 points

    Good to know about ISR and thanks for article....Code is all ISR with push buttons driving all activity, creating data and then sending over a radio.  Not sure what benefit it is to have say a timer that wakes up and kicks the watchdog periodically as this potentially could continue to work even when say the radio shut downs or locks up......

    My approach is to start the "dog" on a pushbutton event (I reset and take out of hold in the ISR ---- I do create a soft-flag here that I clear in main and can move the code to there) and then kick it after the radio returns....If radio doesn't return it reboots the firmware.  I will take advise and move things out of ISR but for now.......

    Still doesn't explain to me though why a step over P1IE puts me right back at main with no 16 second period???

  • +1 in reply to Steve Wenner
    Genius 3190 points

    Good to know about ISR and thanks for article....Code is all ISR with push buttons driving all activity, creating data and then sending over a radio.  Not sure what benefit it is to have say a timer that wakes up and kicks the watchdog periodically as this potentially could continue to work even when say the radio shut downs or locks up......

    My approach is to start the "dog" on a pushbutton event (I reset and take out of hold in the ISR ---- I do create a soft-flag here that I clear in main and can move the code to there) and then kick it after the radio returns....If radio doesn't return it reboots the firmware.  I will take advise and move things out of ISR but for now.......

    Still doesn't explain to me though why a step over P1IE puts me right back at main with no 16 second period???

    Can't quite explain it BUT....removing WDTCNTCL from the setup in main seems to have fixed the issue as it now waits for 16 seconds....Strange (at least to me ) but working.

    Want to add for future users:

    IMPORTANT :  NEVER TRY AND USE WDCTL |= TO SET BITS!!!!!  ALWAYS USE WDCTL = !!!!!

    THE FIRST DOES A READ, THEN AN OR, THEN A REWRITE....A READ PRODUCES 0X69 IN HIGH BYTE WHICH WHEN REWRITTEN TO REGISTER AUTOMATICALLY RESETS THE BOARD DUE TO NOT WRITING A 0X5A IN THE HIGH BYTE.

**Attention** This is a public forum