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.

MSP430F5528: Startup issue: WDT not hold long enough during auto init

Part Number: MSP430F5528

Hello Experts,

I've came across a strange issue where the WDT is restored to early during autoinit intialization. The Wdt it restored right after cinit and subsequently triggers during pinit as this obviously takes longer than one default period. Any suggestions how to avoid this. On the other hand it is not the expected behaviour as the settings suggest that the wdt is silenced as long as user code has not been entered.

MfG Tobias F

  • The watchdog is enabled during reset and must be disabled before it triggers. Usually doing this at the start of main() is fine but sometimes the initialization performed in the C startup takes too long. It has to copy initial values and zero out the bss.

    Compilers can provide a way to hook in code which gets executed before those possibly time consuming activities. With GCC it works like:

    static void __attribute__((naked, section(".crt_0042"), used))
    disable_watchdog (void)
    {
      WDTCTL = WDTPW | WDTHOLD;
    }
    

  • i think i've found a solution. Just added a wdt stop in system_post_cinit, Thats the next hook location right after the wdt is restored and before pinit. Why is there no option in the linker to stop it there too? Its a bit missleading as you think you disabled the wdt for init just to find out its only for cinit

  • 1. The reason lies on the WDT after init will be enabled by default. Normally, the peripheral reconfiguration will not be included in cinit. That is why we need to configure WDT at the beginning.

    2. You can also find this part of code "WDTCTL = WDTPW | WDTHOLD" in every code examples. 

  • yes that circumstances are clear and im familiar with that. The problem is that the settings suggest that the wdt is hold during cinit and fails in pinit. You can spent hours debugging when you thought that the init routine holds it, which it does, but not long enough

  • I am sorry to hear that. I think the good news is that you know the right answer.

**Attention** This is a public forum