Watchdog timer, yes or no and why [SOLVED]

[wangine]

My question is not that simply than look like. I never use watchdog, i always disable this, long time i used for watch ext interrupt pin during to sleep. Normally anyone want the code to run nicely and don't get stuck but i need some advice to light up my opinion. First of all i want to count any ms past during in a execution program and read on randomly functions, no more than 40 seconds. My all timers are configured already and the fast of them is timer 2 at 2ms, used for 2 channels pwm. Now the questions, if i use watchdog

[Ttelmah]

You need to say what chip.

Watchdogs differ most from the 'series' of PIC involved (not the family). So early PIC's all tend to have relatively inaccurate RC watchdogs that will often have -50%+250% timing accuracies!. More modern members of the families often have much better watchdogs.
On a lot of the very old chips the watchdog prescaler is shared with Timer0. On these selecting the watchdog _will_ affect the prescaler available for timer0. However more modern chips usually have a separate prescaler. The place to start is the datasheet for the chip you are using.

[wangine]

The controllers are bought recent, then i think are the new series, on subject is a PIC18F97J60 and PIC18F4550 and i'm still confused, to use or not watchdog timer. Is not difficult to use a timer, so... what to do?

[Ttelmah]

It is actually very difficult to use the watchdog to do anything worthwhile.

Problem is that the commonest problem is not the processor actually stopping, but jumping to an incorrect location. If you have 'restart_wdt' calls scattered round the code, the watchdog won't actually do anything, since these will still be reached....
Unfortunately CCS's appraoch of offering 'automatic' watchdog restarts in delays etc., is just about the worst way to try to use a watchdog.

To use a watchdog properly requires that the restart, is protected by code that makes it impossible to reach _except_ when the code is running correctly. This is then only called when everything is doing exactly what it is meant to do. This way the watchdog can only get restarted, when things are OK.

Then the watchdog should only be added after the code is 100% running correctly.

Some regulatory authorities, require that the watchdog is only enabled after the system has already passed full operational testing.

[wangine]

Hahaha, , is much more than i need to know about watchdog. Anyway my code run now with timer count is on 2ms count but i divide by 2 and my error is 0.5, that operation don't need necessarily a fixed 1 ms, I use just for some filter references not critical. I ask about watchdog because i never use him, and i was thinking is a built in function, like on Arduino for example millis();, return any ms past on code execution and is more easy to implement, and sure more fast .... but in conclusion watchdog is a end story.
Thanks Ttelmah, your answers became fast usually, like others guys here. Awesome forum, awesome users.

[wangine]

I forgot about watch dog and i continue research. Actually exist a built in function to return a timer tick, of course depends on osc rate. I just found

[Ttelmah]

As a general comment (going back to the watchdog), have a look at this site, which gives a very good overview:

<http://betterembsw.blogspot.co.uk/2014/05/proper-watchdog-timer-use.html>

[Ttelmah]

On the timer, 'of course' if you use a timer, you can't change it for anything else, but you can still use an ISR. The point about ISR/NO_ISR, is the timer _wrap_.
If you have a timer ticking at (say) 1mSec, and the hardware handles counts to 65535, then for a 32bit tick counter, _something_ has to handle when the timer overflows. Now the get_ticks function will handle this, provided it is called more often than once every 65536 counts. So for a tick at 1mSec, which you are checking several times a minute, the ISR gains nothing. However if you programmed a tick at (say) 1uSec, and only checked this every second, the ISR is necessary to handle when the timer overflows, since it could have overflowed 16 times in a second.....
You can still add your own extra code to the timer3 ISR, but, you need to understand, that the interrupt is only called on the overflow, _not_ on the tick.
So with your 1.02mSec tick, it'll only be called once ever 67 seconds. Not surprising your scope can't then sync....

[asmboy]

true confession:
I have had to add a watchdog code to two designs i have done for no other reason than legal/regulatory compliance.
One was a very simple military emergency light charger/controller.
the other was a non-life-critical medical monitor device.

In both cases i believed it was a worse than useless addition-
since watchdog reset and recovery code could have added potentially harmful
changes to the well-tested time domain performance of the design, that themselves are test resistant.

I will never use a watchdog unless the customer's requirements demand it.

[Ttelmah]

Interesting. I have to use watchdog's in a lot of code, again for regulatory reasons. However we are always required to test sequence the code, with dummy code replacing the watchdog functions that takes the same time, and the watchdog must record that it has occurred is real use. Then also to demonstrate a watchdog recovery, and the time involved.

Watchdog's can be a very powerful tool. If you look at the link I gave, he is advocating a bit mask, built as segments of the code function correctly, which then enables the watchdog restart. So the watchdog become a 'everything is working' test. This is particularly useful, when there is a lot of other hardware involved, since each segment and it's communications can flag that everything is OK, and if the restart is built to also power down/up these other sections, it can trap hardware errors , and in many cases recover from them. I use a similar approach, and the record made at a watchdog restart, includes the data on which segment/device actually did not flag it was OK (remember RAM is preserved on a watchdog restart), and it can become a fabulous tool, when at routine maintenance machines that are still apparently working OK, are recording restarts from one specific sub-module at increasing frequency. Great time for preventative replacement....

In some ways, watchdog's can be considered like checksums in communication. A vital, and powerful tool that can show incipient failures, and allow you to ensure data is reliable. However the approach of adding a watchdog to code, and scattering restarts around the code, is just like a person coding a checksum, who then at the receive, doesn't actually bother to test it's value. A waste of code space and time. They need to be coded with understanding, and used with care.

[wangine]

I don't know what to say, sincerely i agree the _asmboy_ opinion 100%, but.... in _Ttelmah_ link is a great tip to use the watchdog.
[/url] http://betterembsw.blogspot.co.uk/2014/05/proper-watchdog-timer-use.html [url]
To be on the point because my application who need a watchdog is not a secret, is a scanning photo and image copier with 3 laser devices at 2W,
each one copies a low image at standard 640/360 at 16/9 format. The mechanism is taken from a old and big laser printer. The principle is the same, and the power of each laser color on that speed is reduced as <100mW each one, but the problem is with too many interrupts and if motor stop, laser will develop entire energy and can burn some eyes. Now the answer is again on top. The driver for pwm channels and motor also for all code is a dsPIC33, and my idea to don't overload the first dsPIC has to comunicate with any type of PIC, in my case a 18Fxx family, with a watchdog on to verify any success, pass function of first dsPIC, otherwise restart entire system. The code in dsPIC is directly on each register, is less than 60% C code, is difficult now to put flags and enable watchdog for him, that is why my idea was to use other PIC to monitor, dsPIC send on a 3 pins a condition if all functions pass. The code has worked nicely with a 3-input AND gate conected to pins and to MCLR pin, in case of any function fail, but i want to be more fancy. Again now i still am thinking, i need some tests, for moment thanks for all suggestions.

[Ttelmah]

What you need is to start with the hardware.
An example would be to have the actual drive hardware built so it always turns itself off. It requires a 'kick' (a pulse signal), perhaps every second, and if it does not receive this 'goes off' automatically. If the pulses stop, the dangerous hardware _turns itself off_.

This is 'fail safe' design.

In software you have for example a sequence packet passed forwards between each part of the code. One part is a counter, and one a set of 'I am OK' flags. The supervisor program has to see both the flags going true, and the counter advancing by the correct amount, to accept that the sub components are all working as expected. The flags are like the old 'semaphore' railway signalling, with a train not being allowed to proceed unless it had the semaphore in it's hand, while the counter is rather like the 'distance behind' measure in the railway. Again if the counter does not advance as expected, or the required semaphores don't change, the supervisor code has to switch to fail in a safe manner (stopping the train...). The supervisor can be a program in the main chip, or a separate chip itself, and again the hardware should be built so a signal stopping 'fails' to a automatically safe condition.

A watchdog restart can be used by the supervisor as a way of restarting a particular piece of hardware, but there has to be safe operation if this occurs.

Remember though in some types of system 'stopping' may not be the safe condition. So the hardware needs to be designed to take the system to perhaps a 'reduced' operating mode, rather than a stop in these circumstances. Possibly even a complete alternative reduced system.

You need to draw a big diagram, with 'what must happen', and 'what is going to ensure this'. This must include 'what happens if each part fails'.
You may need to consider 'lateral' ways of giving safety. For instance, if the laser stays on, could you have a system that after a few seconds starts a bright xenon strobe?. This ensures that people automatically 'look away'.

If a device physically 'must always be safe', you may well need to be using a processor that is 'certifiably safe' (look for COTS). This may well rule out your current design....

[wangine]

[gaugeguy]

C O T S
Commercial Off The Shelf

https://en.wikipedia.org/wiki/Commercial_off-the-shelf

[Ttelmah]

Particularly COTS safe & secure.
Stuff that is certified for safe applications.