MSP430F249: Watchdog reset not working, chip freezes

The WDT triggers a PUC reset. In the F2 series a PUC resets some, but not all, of the peripherals. If your startup code assumes that all the peripherals are in reset, it may malfunction when initializing those that aren't.

I don't recall seeing a master list of which peripherals/registers are reset with PUC (vs POR), rather the register summary for each peripheral says. Compare, for example, User Guide (SLAU144K) Tables 12-3, 15-6, and 23-2. If the "Reset" column says "with POR", that implies that it is not reset by a PUC. For those, it's probably best to explicitly reset them during initialization.

Hi Bruce,

we see that the chip freezes completely and not functioning even though watchdog is implemented. Reset via the RST pin works. When we simulate the watchdog functionality, chip resets properly. Is there a possibility chip freeze and watchdog not kicking in ?

You can try to reset all peripherals you have used in application at start of the main function.

How do you tell that the chip freezes? In what state is it left?

My first guess is that your system is resetting (repeatedly) too fast to see. Alternatively, it may get "stuck" before you enable the Watchdog. Try setting a breakpoint on the second line of main().

Hi Bruce,

There is an LED which blinks and RS485 Communication channel through which we can read the parameters. When the chip is stuck, the LED is constantly ON( which is pulled up) and we cannot communicate to read the parameters. This constant LED On behavior is not controlled in our firmware code. No response from the chip when it freezes. This is why we concluded the chip is being stuck. A Pin reset or a power cycle brings it to the normal state.

I cannot put a breakpoint as this issue is reproduced in filed (on street cabinets) under certain circumstances ( No root cause found yet)  and debugger cannot be connected in this case. Also this issue is very intermittent, have to wait for more than one or 2 weeks.

Under what circumstances the chip can reset continuously ? 

It's hard to say much without knowing your methodology. Does your code ever stop the Watchdog (WDTHOLD)? When does it (first) light the LED? Does the Watchdog Reset ever succeed (in the sense of properly restarting your system)?

Is it possible that the condition/event that is triggering the timeout is something electrical?

Does your code ever stop the Watchdog (WDTHOLD)? 

- Only when the Software update happens and no software update is triggered when this issue is seen.

When does it (first) light the LED?

- A LED blink is happening in LED Task which is called after all the initialisation.

Does the Watchdog Reset ever succeed (in the sense of properly restarting your system)?

-Yes, we simulated same by an infinite loop in the process wvery 30 seconds and watchdog triggers the reset properly. Also checked by commenting the watchdog refresh code,

Is it possible that the condition/event that is triggering the timeout is something electrical?

-Not sure about this. Can any electrical noise cause this type of issue ??

I have given the watchdog and init code below for reference.

...

WDTCTL = WDTPW + WDTSSEL + WDTCNTCL;

initIo();

timerInit();

initProcesses();

__enable_interrupt();

while(1)

{

//call processes 

//refresh watchdog

}

...

Few comments here that:

1. when the issue happen,  do not reset or power cycle the device, read the PC value to see where the code running is more details to do this you can follow this document

4857.Read MSP430 PC counter and register.pdf

2.  Make it clear how to fast and stable to reproduce this issue

3. Running our demo code to see if it has the same issue like msp430x24x_wdt_06.c (ti.com) 

Hi Gary,

We will be working on your inputs. I will keep you posted on my findings.

The issue is reproducible only in customer site intermittently, once in  1or 2 weeks.

Any update from your side?

Hi Gary,

The issue is only reproducible in field in Abu Dhabi, not in our lab and it is not feasible to connect debugger and read the PC value as you mentioned. It takes approximately a week or 2 in filed to see this issue.  Watchdog code works fine and i can able to see the watchdog reset.

Anything else we can conclude with the information we have above ? 

Hi Chinmaya,

For this device F249 is very old device, so this product should be running for many years, right? If so, dose this issue happen in the past few years?

If any change on the hardware or software recently?

The device and the module is running in filed from past 13+ years and this issue was reported a year ago. Earlier to that this issue was never reported from anywhere. There was no change in the hardware or software for past 5+ years.

Chinmaya P said:

A LED blink is happening in LED Task which is called after all the initialisation.

Since the MSP430 watchdog is pretty simple, it can't catch all problems. It isn't that difficult to have a failure in the code that keeps resetting the dog but doesn't actually operate correctly. Your code seems to be fairly complicated which provides plenty of opportunities for trouble. Including things that turn up only after a particular sequence of events.

The LED staying on should be a clue.

That is too weird that it just happen recently. One thing that come to my mind that make this issue is the clock is failed that sourced to the WDT. Have you capture the power supply if any noise there?

No. Can you help me with that? How to capture the power supply if there is any noise? 

You can use a oscilloscope to capture the wave forms of  the VCC and enable the trigger mode and also enable the measurement of the pike to pike and min max value of the VCC.