MSP430 Hangs up even when WDT timer is enabled

A crystal failure doesn’t trigger an WDT reset. It switches MCLK to DCO and the MSP continues. Which may of course make the MSP hang if the DCO speed is too high for the current supply/core voltage or if the code cannot cope with the speed change. Since the WDT only triggers a PUC, not a BOR, the hardware (including the clock system) is not immediately initialized. It takes the boot code to do so. But if the MSP is in a state where the boot code cannot be executed (e.g. DCO too high), the MSP will crash again. And crash again each time the WDT triggers.
Also, it should be noted that, since the WDT only triggers a PUC, many hardware components aren’t re-initialized before program start. (e.g. DMA or timers, which will even have their interrupts still enabled) This may cause the application to crash as soon as it restarts.

I'm facing the same scenario of WDT failure in my MSP430F5419A. I'm operaing my uC with internal DCO of 16MHz tuned with FLL and Setvcore to Level 3 as the clock freq is high. What could be the reason for failure even when in internal DCO?

Jens-Michael Gross said:

Another problem is that in some projects, the WDT is disabled during the variable initialization, to avoid the WDT triggering during the data copy (32ms timeout). If the MSP crashes during this phase, the WDT is off and the MSP remains crashed.

In the variable initialization case, how to find which section is making the problem?

Manoj Srinivasan said:

In the variable initialization case, how to find which section is making the problem?

You would want to check this thread (there's more) to have an idea

"What could be the reason for failure even when in internal DCO?"

The code could stick in an endless loop that intentionally triggers the WDT but unintentionally never exits. :)
Keep in mind that on 5x family, you can get a DCO fault (and therefore OFIFG set) when the DCo is on its highest or lowerst step. Which usually means that the selected frequency range doesn't match the FLL target frequency, so the FLL bumps the DCO to its highest or lowest setting for this range. If your code checks for OFIFG, this might be an endless loop.
Also, before switching to 16MHz, PMMCOREV needs to be set to 3 and to do so, VCC needs to be high enough. Else the MSP will be kept in SVS-reset. This might cause the MSP to crash, as the WDT, even if it triggers (a PUC), does not reset the SVS (reset on BOR).
A problem could be a slowly rising VCC (but after a manual reset, VCC is already high enough and stable).

Check the users guide register descriptions for which bits are reset at which reset level. As I said, the WDT is only triggering a PUC, while a lot of things are only reset on a POR or BOR.

Anothe rpossible reason could be that the firmware is not aware that after a PUC, some peripherals are stilla ctive. Especially the timers. So if the applciaiton sets GIE, it will get timer itnerrupts if the timers were active before the WDT reset. Even if it is not prepared to handle them at this poitn of initialization. This may lead to an eternal reset loop if the device gets a PUC for some reason (not only WDT) after having properly started once.

"In the variable initialization case, how to find which section is making the problem?"

It depends on your compiler, your framework (if any) and the device you're using.
The MSPGCC 3.23 always disabled the WDT before initializing the variables. You had to manually enable it at start of main. I replaced the whole init code to trigger the WDT while copying rather than switching it off. Made the startup a little bit slower, but increased reliability.
On others, you can add a user-defied function od code section of a special name, to disable the WDT after power-on (or switch it to a longer period if available, which is better than switching it off), before initializing the vars.