WDT Testing

[Mike Walne]

I'm wanting to test a WDT for reliability.

I will have an unattended 18F series PIC permanently connected to a mains power source with battery (super-cap) backup.
The PIC will be running continuously, even during mains fail.
In the event of a malfunction the WDT is to restart the PIC.

I want to simulate the effect of a severe disturbance which will upset the PIC.
The idea is stop the PIC performing its normal programmed sequence and cause a restart.
I don't want to kill the PIC in the process.
Does anyone have any tried and tested tricks which cause PICs to go off into never-never land?

Mike

[PCM programmer]

You could ground the CLKI pin on the PIC for a period longer than the
WDT timeout. Since the PIC has no clock, the WDT will not be restarted
in code and it will timeout. You have to use the NOFCMEN fuse for this
test, to prevent the PIC from switching to the internal oscillator.

[asmboy]

i would carefully tease the brownout function by slowly degrading the Vdd pin.

another trick is to weakly couple Vdd thru a resistor and variably superimpose the audio output of an AM or FM radio onto the PIC power using a divider.

[Ttelmah]

It's quite difficult to 'simulate', since the whole point of the watchdog, is to catch code that is still running, but doing things it shouldn't.
This is why for a watchdog to really 'work', all locations where 'restart_wdt' is met, should be trapped so they cannot be reached by code doing a random walk, and be testing the 'I am working' flow of the code before doing the restart.
Both the suggestions posted prove the 'recovery', but are actually testing other things (clock failure, which could be caught by FSCM instead, and brownout).
One simulation of a really nasty failure, that could prove if the watchdog is functioning as it should is a 'random jump'. Ages ago when I needed to test the actual ability of a watchdog to recover the system from spurious operation, I added a short entry to a timer interrupt, that at a pseudo random interval (it used a pre-generated look up table and counter), did a jump to an undefined location in memory (it pulled bytes from a couple of SFR's, and jumped to the resulting address).
The code would run normally till this hit, and then for the recovery to be working properly, had to do a 'friendly' restart once the normal flow was seen to be no longer happening.

[asmboy]

one simple tip:
if there is an uncommitted pin on your PIC, set it for input, pull it high and then poll it in your main DO loop, as the entry to a closed no-exit loop WHILE when said pin goes and stays LOW. you know what to do next - tease it closed to ground for varying lengths of time less than the WDT interval and work your way up to the actual trigger point. very low code overhead and negligible time domain change so long as pin stays high.......