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.

MSP430F2132: Disable Watchdog Routine jumps to reset vector

Part Number: MSP430F2132
Other Parts Discussed in Thread: MSP-FET

I am working on some legacy code that has been operational for the last 5+ years (since i joined the company) and I noticed on one of our boards with an MSP430F2132, in debug mode, when i stepped over the DISABLE_WATCHDOG routine shown below, it would immediately jump to reset vector.

Watchdog Macros used:

#define WDTCR_INIT()                     { WDTCTL = (U16)(WDTPW+WDTHOLD+WDTIS1); \
                                                            WDTCTL = (U16)(WDTPW+WDTCNTCL+WDTSSEL+WDTIS1); }



It seems that the 3rd parameter WDTIS1 (division of selected clock source) is causing the problem. If i remove it, it will execute the expected command to disable the watchdog, however my concern is that this code has been operational for many years and only now it has started to give me some issues.

I use IAR MSP430 IDE and there have been several updates to its compiler and ide over the year (not sure if this could be in any way related)

Is there a reason why WDTIS1 in the Disable Watchdog Macro would force a jump to the reset vector?



  • Hi Alki,

    I have to admit, I have never seen


    to stop the WDT.  Typically it is just WDTPW + WDTHOLD.  Not sure exactly why setting the clock divisor would cause this.

    Under normal operation (not debugging) you don't see any issues, right?

    It probably has something to do with the debugger, especially when you are single stepping. 

    Which debugger are you using?

  • I was able to generate your symptom using your macros on an F2013 using a G2ET Launchpad that didn't have the 32kHz crystal connected.

    Try adding:


    You mentioned a particular board. I wonder if something has happened to the crystal on that board. I've seen the fail-over act somewhat haphazardly on F2 devices.

  • Hey Dennis, 

    I understand and agree on the advised macro to disable the watchdog. This is an inherited code that was previously working but no longer in debug mode, so i was just trying to wrap my head around what went wrong. In Release mode, the code works without an issue.

    I use the following debugger:

    Its not a major issue, and looks like its somehow linked to the debugger / debug mode so i can work around that for now with the proposed macro. Thanks for your help

  • Hey Bruce, thanks for the reply. I dont have any external crystal on this board and i am using ACLK=VLO. The funny thing is that I have been able to get it to run through the macro after many failed attempts, and when it does work, it takes approximately 60seconds to step through that single line. 

    The best solution is to remove WDTIS1 from the DISABLE_WATCHDOG and only set it on the INIT_WATCHDOG macro.

    Thanks again for taking the time.

  • Hi Alkiviadis,

    Since it looks like you were able to resolve your issue, I'll change the status of this posting to RESOLVED.
    If this isn’t the case, please click the "This did NOT resolve my issue" button and reply to this thread with more information.
    If this thread locks, please click the "Ask a related question" button and in the new thread describe the current status of your issue and any additional details you may have to assist us in helping to solve your issues.

  • Its not a major issue, and looks like its somehow linked to the debugger / debug mode so i can work around that for now with the proposed macro.

    Looking through the MSPDebugStack_OS_Package_3_15_1_1 source code, can see functions which get/set the watchdog control register values. I haven't understood the logic, but perhaps the program setting WDTIS1 interferes with how the MSP-FET code handles the watchdog while stepping during the debug.

  • Hey Chester, it could very well be something along those lines. Looking at the disassembly i can see its correct mov.w 0x5A82 to WDCTL register.

    When i step through the code it fails (reset vector), but if i manually update WDCTL register directly with 0x5A82 it works fine.