• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 1475 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.

MSP430F5308: WDT incorrectly fires a RST/NMI (BOR) 04 event or BOR 02 the the first time it is triggered

Blake Carpenter
Expert 6585 points
Part Number: MSP430F5308

Hi, 

The customer wants to trap the SYSRSTIV for a 16 to make sure he correctly handles an WDT event.

But from a cold start, the first time the WDT is triggered (using an infinite loop), the part triggers a BOR instead of PUC and the SYSRSTIV contains either a 04 (RST/NMI) or a 02 i(BOR) nstead of the expected WDT.  Subsequent triggers yield the expected 16.

The engineer has spent several days troubleshooting it, and I sat for 2 hours yesterday throwing out ideas, but nothing seemed to help.

Here is his WDT control:

   WDTCTL = (WDTPW | WDTCNTCL | WDTSSEL__ACLK | WDTIS_5);   // WDT interval 8192

Any Ideas of where to look?

  • 0
    TI__Guru 70246 points
    Hi Blake,

    Do they have anything else enabled in their system (could be something else triggering the reset?)
    I'm also wondering if it actually could be impacted by the way they are observing the value of SYSRSTIV. SYSRSTIV is read sensitive because it is an interrupt vector - if you read it, then it will clear the highest priority source. I suspect the 4 or 2 are coming from the debugger resetting the part when you load it or do a reset in the debugger, and that this value is not getting cleared until after you have checked it the very first time. I would recommend reading the value into a variable at the very beginning of the code and then viewing the variable - the reason for doing this is to clear the initial SYSRSTIV value from when you first started the device from the debugger, when it will have a high priority reset source (e.g. 4h). If you have a breakpoint just after you read SYSRSTIV into the variable, the very first time you hit it would be at the beginning of the code before you have actually set up the watchdog, and it should read out the value from loading the code etc. Then when you hit it the second time, it should be 16h for your watchdog timeout. Does this make sense?

    Regards,
    Katie
  • 0 in reply to Katie Pier
    TI__Expert 6585 points
    Hi Katie,

    Your suggestion worked perfectly! He also found he can directly write a 0 in SYSRSTIV which worked as well. I will leave it to him to decide which he will ultimately use.

    He had long sense quit using the debugger as it was causing him problems.

    Thanks so much for the suggestion - saved us a bunch of fruitless back and forth debugging.

    Best Regards,

    Blake
  • 0 in reply to Blake Carpenter
    TI__Guru 70246 points
    Excellent! I'm so glad I was able to help. :-)
    -Katie

**Attention** This is a public forum