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

MSP430F169: Watchdog strange issue

Didier Didier
Prodigy 100 points
Part Number: MSP430F169

Hi,

I have a strange issue with Watchdog. I would like restart program with a PUC. For that I write bad passd into watchdog.

I read in SLA049f 10.2.2 'When the WDT is configured to operate in watchdog mode, either writing to WDTCTL with an incorrect password, or expiration of the selected time interval triggers a PUC'

I put a breakpoint in line 'CLR &WDTCTL' and make step by step in assembly windows. This commande write bad passd and never set wathdog in NMI mode.Then I think Processor read reset vector and jump to 'init:'

Against all expectations the processor jump and execute code at 0xFFFC!! That is the NMI vector (Wathdog is not configured for NMI)! BUT MORE STRANGE processor don't use that as the jump address (vector) but execute code and run through....

An explanation would be really welcome

Didier

#include "msp430.h"                     ; #define controlled include file

        NAME    main                    ; module name

        PUBLIC  main                    ; make the main label vissible
                                        ; outside this module
        ORG     0FFFEh
        DC16    init                    ; set reset vector to 'init' label

        RSEG    CSTACK                  ; pre-declaration of segment
        RSEG    CODE                    ; place program in 'CODE' segment

init:   MOV     #SFE(CSTACK), SP        ; set up stack

main:   NOP                             ; main program
//        MOV.W   #WDTPW+WDTHOLD,&WDTCTL  ; Stop watchdog timer

        CLR     &WDTCTL

        JMP $                           ; jump to current location '$'
                                        ; (endless loop)
        END

  • 0
    Prodigy 100 points

    Hi,

    I investigate and I found that:

    If Wathdog is clocked by ACLK or return to ACLK after SMCLK failure then Watchdog module don't work correctly:

    Write a bad password don't reset the CPU, but load PC with 0xFFFC and execute code at 0xFFFC and after...

    I never read that this behavior was correct. I would like TI to take a position on this

    Thanks,

    Didier



  • 0 in reply to Didier Didier
    Prodigy 100 points

    Sorry, just a mistake...

    I would like say DCOCLK, not ACLK

  • 0 in reply to Didier Didier
    Prodigy 100 points

    Investigation... continue...

    In fact It's CPU seem be OK.
    When I debug with IAR and MSP-FET430UIF, if I put a breakpoint in the same condition I write describe before, the debug chain jump to 0xFFFC. I think is a probe bug issue

  • 0 in reply to Didier Didier
    TI__Mastermind 26420 points

    Hey Didier,

    I'm going to guess this is somehow a debugger related issue.  When debugging with JTAG, it can interfere with CPU behavior and timing.  Also, I don't think it's possible to debug through a PUC/reset so the debugger can be interfering.  

    For testing this, I would probably test it with the MCU free running.  I think the easiest way to do this would be to set/toggle a GPIO at start-up and then a different GPIO before trying to trigger a PUC.  That what you can see if the PUC is being generated and the MCU is reset as expected.  

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    Prodigy 100 points

    Hi ,

    Thank you for your response.

    When I think about debugger issue, I put breakpoint at reset program entry. The behavious is différent: The CPU work finnely. GPIO for debug is a solution to debug, but breakpoint finally is OK also.

    I didn't think about the debug issue because when a hard reset occure, debuger work always fine. But today, I need to delivery software for production and make deep test in unusual situation... look first cycle after PUC.

    In fact, I can say now: Don't put breakpoint after wathdog passwd fail and step by step runnig, if DCOCLK is used, and be suspicious in general after reset

    Sorry for english, hope it is understandable


    Regards,

    Didier

**Attention** This is a public forum