Simple watchdog, I hope.

[electromanj]

Hello all, I want a watchdog timer in case a project locks up. I want to keep it simple so I used an RC circuit where the capacitor gets recharged at the beginning of each method and if not the resistor discharges and either the prop senses a low input or you could reset the prop all together. The circuit is as follows:

P2 |( Vss
-^^-
Sorry about the schematic I tried to draw it in prop tool but couldn't remember how.

P2 is connected to the positive pin of a 1000uf electrolytic capacitor. The negitive pin is connected to VSS. A 51K ohm resistor is paralleled to the cap between P2 and Vss. (gives about 42 seconds of time delay.)

P2 is set to output, then P2 is set to input and looks for a low signal.(Capacitor is discharged).

Here is my test code.

CON

_clkmode = xtal1 + pll16x ' use crystal x 16
_xinfreq = 5_000_000 ' 5 MHz cyrstal (sys clock = 80 MHz)



Pub setup
dira[11]:=1 'set p11 to output
outa[11]:=1 'turn on led
waitcnt(clkfreq*2+cnt) 'wait 2 seconds
outa[11]:=0 'turn off led ====checking that led is operating
dira[2]:=1 'set p2 to output
outa[2]:=1 'set p2 high to charge cap
waitcnt(clkfreq*1+cnt) 'wait one second
outa[2]:=0 'set p2 low,cap should be charged
dira[2]:=0 'set p2 to input
repeat until ina[2]==0 'wait for p2 to see cap is discharged
blinker 'go to blinker

pub blinker 'blinker method: this would normally reset prop or return to a main method
repeat 50 'blink led 50 times
outa[11]:=1 'set p11 high turn led on
waitcnt (clkfreq/5+cnt) 'wait 1/2 second
outa[11]:=0 'set p11 low turn led off
waitcnt (clkfreq/5+cnt) 'wait 1/2 second

I have a few questions:
1. I am charging the cap really fast. Is that going to be a problem with current on P2? Do I need to add a series resistor to limit the current?
2. Could I reset the prop safely with another I/O pin, such as If P2== 0, P3==0 with P3 connected to the res pin?
3. Is it OK to use the same I/O pin to charge the cap and then sense the discharge, or am I being an overachiever?
Thanks for any help.

[pgbpsu]

electromanj-

I'm not sure I can be much help with the hardware side of things (current drive, etc) but I think this is a great idea and I'll be watching what other have to say.

Why use P3 to reset the prop? If you get P2==0 you can simply use the reboot command.

BTW, the waitcnt(clkfreq/5+cnt) waits 1/5 a second doesn't it? This is probably just an old comment in the lower blinker method....

Best of luck.

[JonnyMac]

Since you need the Propeller clock to be running to get to a reboot command, why not handle it in code?

Here's a method that you would launch with cognew, passing the global variable used as your watchdog timer and the time limit your program will tolerate before rebooting. It's up to yor foreground code to clear the watchdog variable when things are running normally; this code will increment that variable every millisecond.


pub watchdog(wdpntr, limit) | t

' wdpntr = hub address of watchdog variable
' limit = milliseconds of "stuck" before Propeller reboot

long[wdpntr] := 0 ' reset

t := cnt ' sync
repeat
waitcnt(t += clkfreq/1_000) ' wait 1ms
long[wdpntr] += 1
if (long[wdpntr] > limit) ' exceed watchdog limit
reboot ' yes, reboot

If you're going to use an external circuit then you should probably tie it to the RST\ pin.

[electromanj]

Thanks to both of you.
Very good points.
@pgbpsu thank you, believe it or not I had never seen the reboot command! I never seem to see something until I'm looking for it. (I should put that as my signiture).

@JonnyMac I have been strugling and tried many variations of an "in program" watchdog with no success. I will be trying this out tomarrow. Thank You!

I guess what I really want is the best of both worlds. A watchdog within the program that moves back to a main method if "x" doesn't happen. Along with an external watchdog that resets the whole thing if "x" plus offset time doesn't happen. Internal say 30 seconds, full reset after 60 seconds.

I also added a series resistor to limit inrush to the cap. takes less time for the watchdog to time out. Probably because I still am charging the cap for the same amount of time.

[Linus Akesson]

Two thoughts:

1. Don't clear the output pin (OUTA[2]) between the recharge pulses. Just change its direction (DIRA[2]). Otherwise there's a brief period during which you're draining the capacitor back to ground level.

2. Choose a smaller capacitance and a larger resistance. Power consumption will be lower, and you can avoid using an electrolytic cap.

[JonnyMac]

@JonnyMac I have been struggling and tried many variations of an "in program" watchdog with no success. I will be trying this out tomorrow. Thank You!

You're welcome. Keep in mind that this code needs to run in its own cog. You should define a long for the timer and an array of longs (16 should be fine) for the stack for that cog. Launch it like this


cognew(watchdog(@wdtimer, 100), @stack)

This assigns wdtimer as the watchdog variable that must get cleared by normally-running code. The limit here is 100ms -- set as required for your project.

[Paul Baker]

Im with Jon, using an RC delay just uses up a pin. Since you are using a cog running code to check the pin it offers no benefit (it would be different if it was a hardwired watchdog in silicon).

But to answer your question, should you ever come across a capacitor charging situation again. I'm the person who did the testing of the Propeller chip for the datasheet and the Propeller output pins are self limiting somewhere in the vacinity of 40mA, so you will not damage the chip.

However some strange things could potenial occur from not current limiting the charging of the capacitor. If the power being supplied to the Propeller has enough inductance (usually from not adequately bypassing the power supply with capacitors) then the Propeller could potentially brown out or reset which results in unpredicatable behavior (or predictable but undesirable behavior).