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.

Watchdog timer not working correctly. Timing is not right!?

I am trying to setup a basic watchdog timer.  Here we go, MSP430 F5310.


Let's start with something simple and setup for a reset PUC of 16 seconds.  So here's what I will use.  The ACLK is based on the 32KHz XTAL1.  XT1 LF mode. 

UCSCTL4 = 0x44;  This means ACLK is set is set to 000b which is XT1CLK. 

Here's the code:

int main(void) {
    unsigned int p=0;

    WDTCTL = WDTPW | WDTHOLD;    // Stop watchdog timer
    unsigned int value = UCSCTL4;
    WDTCTL = WDTPW | 0x23;    // select ACLK as watchdog source 011b = 16s @ 32.768kHz

    while(1);
    return 0;
}

But it is not triggering at 16s.  It's more like a minute or so.  I also tried switching to use the SMCLK which is based on the system clock but that timing also is not right  when I do the calculations.  So why doesn't it work?

  • Okay, I just got it to work using the REFOCLK as the source for ACLK.  That's funny because according to the spec REFOCLK and XT1 clocks are both 32768 Hz.  So why doesn't XT1 source work correctly on ACLK???

  • in you first example your external watch crystal is not configured

    look on UCS section in documentation and on code from TI examples

    (with my little modyfication)

    //******************************************************************************
    //  MSP430F530x Demo - XT1 sources ACLK
    //
    //  Description: This program demonstrates using XT1 to source ACLK
    //  ACLK = LFXT1 = 32,768Hz	
    //  //* An external watch crystal between XIN & XOUT is required for ACLK *//	
    //
    //               MSP430F530x
    //             -----------------
    //        /|\ |              XIN|-
    //         |  |                 | 32kHz
    //         ---|RST          XOUT|-
    //            |                 |
    //            |                 |
    //            |                 |
    //
    //   B. Nisarga
    //   Texas Instruments Inc.
    //   Dec 2010
    //   Built with CCSv4.2 and IAR Embedded Workbench Version: 4.21
    //******************************************************************************
    #include <msp430f5310.h>
    
    void main(void)
    {
      WDTCTL = WDTPW + WDTHOLD;                 // Stop watchdog timer
    
    
      P5SEL |= BIT4+BIT5;                       // Select XT1
    
      UCSCTL6 &= ~(XT1OFF);                     // XT1 On
      UCSCTL6 |= XCAP_3;                        // Internal load cap
      UCSCTL3 = 0;                              // FLL Reference Clock = XT1
    
      // Loop until XT1,XT2 & DCO stabilizes - In this case loop until XT1 and DCo settle
      do
      {
        UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG  + DCOFFG);
                                                // Clear XT2,XT1,DCO fault flags
        SFRIFG1 &= ~OFIFG;                      // Clear fault flags
      }while (SFRIFG1&OFIFG);                   // Test oscillator fault flag
      
      UCSCTL6 &= ~(XT1DRIVE_3);                 // Xtal is now stable, reduce drive strength
    
      UCSCTL4 |= SELA_0;                        // ACLK = LFTX1 (by default)
      
      __bis_SR_register(LPM3_bits);             // Enter LPM3
    
    }
    
    

  • I just got it to work with the REFOCLK which is also 32kHZ.  I'm guessing the REFOCLK is some kind of internal built-in clock that isn't an external crystal oscillator.  how reliable is this and what benefit is it going from using REFOCLK to XTAL1CLK ?  I did not have to setup the REFOCLK and get it to stabilize.

    If they are both the same frequency, then what is the purpose of using one over the other? 

  • REFOCLK is very convenient and reliable but not accurate. If you need more accuracy, you have to use a crystal.

  • I see.  Actually, I don't need too much precision.  Reason being is this is used for watchdog POR.  I have a flash device that takes a max. of 2 mins to perform chip erase or 30 seconds typical.  So I have to set my watchdog to 2 min 8 seconds.  I think it should be accurate down to the seconds no?  If it's off by fractions I'm okay.  But if it's off by 10+ seconds, that's a problem.  

  • I would expect the accuracy to be within +/- 2%. This translates to +/- 2.5 sec over a 128 seconds period. Note that this is almost +/- half of an hour over one day!

  • Okay.  I am implementing using a interval based watchdog timer.  So basically, in order to prevent the watchdog interrupt service routine to occur, I just need to reset the WDTCNTL and write 1 to it as often as possible (in this case, atleast once every 16 seconds) .

    Am I doing this right?  So far, I've tested it and it seems to work.  If the WDTCNTL is not written and is too late, (I hardcoded a while(1) loop), then the watchdog interrupt happens and it jumps to the WDT ISR. 

    So, during a flash chip erase (which can take a max of 2 mins), what I do is use a global counter.  When the counter reaches a value of 8 (8x16=128 seconds), then do a POR in the WDT ISR.  Note,  this means that the WDT ISR has already kicked off 8 times.  And after 8 times, the WDTCNTL was not cleared or the global counter has reached a count of 8, then it will force a s/w POR.  However, if the WDTCNTL was cleared, then at the same time the global counter variable will be reset back to a count of 0.

    I think I'm doing this right?

  • Vern Yip said:
    according to the spec REFOCLK and XT1 clocks are both 32768 Hz.

    Well, ‘’according to the spec", LFXT1 is anything up to 50kHz and above fault trigger frequency (somewhere <10kHz), depending on the attached crystal.
    Typically, a 32768Hz watch crystal is used on XT1, but other values are possible – and without a crystal, and proper init sequence, default frequency of XT1 is 0Hz. (in which case ACLK will switch to REFO as fallback)

    Besides this, yes, what you describe sounds good. And I appreciate that you don’t (ab)use the WDT as a “if the software hangs, reset the chip” hardware “fix” for software bugs. Which is what most people do (and which won’t really work as intended in most cases).

**Attention** This is a public forum