Serial communication

1) Some _bad_ processors are using the processor clock to drive a watchdog just as if it was a normal timer. Obviously, that means that if you stop the clock (often possible with processors that have power-save support), then the watchdog will also stop seeing time. If the watchdog doesn't see time, then it will obviously no longer perform any watching.

2) Sometimes, a processor can lock up in a way that the reset signal will not restart the processor fully. To one part, this may be caused by bad internal design - some state machines not being correctly reset by the reset signal. To some parts, you can get an electric latch-up, in which case the semiconductors in the chip behaves as a tyristor - shorting until you remove the current. Such a latchup will then require that you can remove the power from the processor. Sometimes, it's enough to remove the power a very short time. Sometimes, capacitors gets charged enough that it may take minutes or hours for them to discharge enough that the latchup problem ends. Obviously, a good design should protect all processor signals from overvoltages, but that doesn't mean that it can't happen.

An external watchdog always have its own time base - normally based on an external or internal RC circuit. That means that you will know that you fulfill the requirements of some standards - that the supervision circuit has independent timing.

An external watchdog is powered separately, which means that it can be used to turn off the power to the processor and thereby force a cold-start reset.

But another thing already covered in this thread: A watchdog should not be kicked by automatic logic. Too many designs are using timer interrupts or similar to kick the watchdog. That means that the program may be stuck in an infinite loop somewhere, while the interrupt is still ticking constantly and keeping the watchdog serviced.

The goal with a watchdog is to minimize the probability that the watchdog gets serviced if the system is in any state where it isn't fully in control.

You want to have a lot of validation tests before you perform a kick - something like:

if (uart_working
&&  communication_task_working
&&  rtc_ticking
&&  uptime_ticking
&&  last_i2c_comm_age < I2C_FAIL_TIMEOUT
&&  last_spi_comm_age < SPI_FAIL_TIMEOUT
.
.
.
&& data_integrity_ok) {
    // I'm reasonably confident everything is ok.
    // Now kick watchdog
    kick_register = MAGIC_KICK_PATTERN;
}

So on one hand, you should only kick the watchdog when you are very sure that everything is ok.

On the other hand - the watchdog is not a random safety line that should be too much relied upon. If you get a watchdog reset, then it's time to figure out why - that is an indication that you have a hardware or software error that should be solved. I'm not fond of equipment that performs random resets once/day or week for some magic reason. "But it works" is the wrong answer. It obviously is not working if the watchdog gets used.

1) Some _bad_ processors are using the processor clock to drive a watchdog just as if it was a normal timer. Obviously, that means that if you stop the clock (often possible with processors that have power-save support), then the watchdog will also stop seeing time. If the watchdog doesn't see time, then it will obviously no longer perform any watching.

2) Sometimes, a processor can lock up in a way that the reset signal will not restart the processor fully. To one part, this may be caused by bad internal design - some state machines not being correctly reset by the reset signal. To some parts, you can get an electric latch-up, in which case the semiconductors in the chip behaves as a tyristor - shorting until you remove the current. Such a latchup will then require that you can remove the power from the processor. Sometimes, it's enough to remove the power a very short time. Sometimes, capacitors gets charged enough that it may take minutes or hours for them to discharge enough that the latchup problem ends. Obviously, a good design should protect all processor signals from overvoltages, but that doesn't mean that it can't happen.

An external watchdog always have its own time base - normally based on an external or internal RC circuit. That means that you will know that you fulfill the requirements of some standards - that the supervision circuit has independent timing.

An external watchdog is powered separately, which means that it can be used to turn off the power to the processor and thereby force a cold-start reset.

But another thing already covered in this thread: A watchdog should not be kicked by automatic logic. Too many designs are using timer interrupts or similar to kick the watchdog. That means that the program may be stuck in an infinite loop somewhere, while the interrupt is still ticking constantly and keeping the watchdog serviced.

The goal with a watchdog is to minimize the probability that the watchdog gets serviced if the system is in any state where it isn't fully in control.

You want to have a lot of validation tests before you perform a kick - something like:

if (uart_working
&&  communication_task_working
&&  rtc_ticking
&&  uptime_ticking
&&  last_i2c_comm_age < I2C_FAIL_TIMEOUT
&&  last_spi_comm_age < SPI_FAIL_TIMEOUT
.
.
.
&& data_integrity_ok) {
    // I'm reasonably confident everything is ok.
    // Now kick watchdog
    kick_register = MAGIC_KICK_PATTERN;
}

So on one hand, you should only kick the watchdog when you are very sure that everything is ok.

On the other hand - the watchdog is not a random safety line that should be too much relied upon. If you get a watchdog reset, then it's time to figure out why - that is an indication that you have a hardware or software error that should be solved. I'm not fond of equipment that performs random resets once/day or week for some magic reason. "But it works" is the wrong answer. It obviously is not working if the watchdog gets used.

This isn't a threaded forum, so how about writing all new comments at the bottom of the thread? Or is it then too easy to figure out what new messages to read?

Thank you very much for the nice explanation. As mentioned earlier I faced a problem of program stops (may be due to voltage spikes). I added some filtering and made some changes in component values in RESET circuit . This gave good results. Still I wanted to take extra precaution. It is not that I am using external watchdog instead of trying to improve my design
An external watchdog is powered separately,
Is it the case always? I use the same power source for both and the external supervisor circuit is expected to RESET my processor if it stops.Is it OK?

Component values in reset circuit? Are you not using a tripod - a special reset chip just taking VCC, GND as inputs and having reset as only output? RC resets are seldom good.

Powered separately as in having a separate lead for power. An internal watchdog is powered from the same VCC leads as the processor core, which means that the watchdog can't just cut the power to the processor. With an external watchdog, it's possible to have the watchdog cut the power for a second to the processor by letting the watchdog drive a FET.

I tried supervisor IC DS1232. Working well.It has got a watchdog also which is monitoring the ALE pin of my uC
toggling an external watchdog with ALE is no good, ALE can, and most likely will keep running with runaway code.

Anyhow the '1232 is a supervisor AND watchdog, so why do you still talk about the RC reset.

I, personally, am of the opinion that an internal watchdog (ONLY the kinds that require two consequent writes to be fed) is a better choice, but here is a case where opinions differ. Anyhow there is no discussion about two points
a) any WD is better than none
b) if the WD fires you have a problem that you should fix

Erik

Why do I consider an internal watchdog a better choice?
I think the likelyhood of a port pin toggling in runaway code is greater than two specific consequent writes

Earlier I was using RC circuit. Now started using DS1232

"I think the likelyhood of a port pin toggling in runaway code is greater than two specific consequent writes"
There exists intelligent external watchdogs that are using some form of protcol.
Possibly an I2C message, or at least a pulsed sequence with limitations for max/min pulse length and pulse distance.

An external watchdog that only needs a low-to-high (or high-to-low) transition with a maximum delay is definitely dangerous. The code may have a lot of OP-codes that may affect the processor port.

Using an NXP LPC23xx processor, the situation could be improved by using the mask registers, so the relevant pin is write-protected between the kicks, making sure that just a wild port write with a random value will not affect the watchdog.

An external watchdog that only needs a low-to-high (or high-to-low) transition with a maximum delay such as the ever popular '1232 is definitely dangerous

as stated

Erik