View Full Version : Using a Cog as a watchdog

william chan
04-22-2008, 08:08 PM

I am planning to use one cog of the Propeller as a watchdog.

My questions

1. In what situations would the Propeller clock or PLL stop or hang, preventing the watchdog cog from doing it's job?
2. What is the best way for the watchdog to watch all other cogs?
3. If only one cog has hung and the watchdog detects the problem, how can the watchdog reset only that problematic cog?
4. Would it be advisable for the watchdog cog to physically control the RST pin, in case a whole chip reset is required?
If the watchdog pulls the RST pin, would it immediately kill itself?

www.fd.com.my (http://www.fd.com.my)
www.mercedes.com.my (http://www.mercedes.com.my)

Mike Green
04-22-2008, 08:47 PM
1) Theoretically, one of the other cogs could execute a CLKMODE instruction setting the clock generator to an unstable state. For example, setting XTAL3 might cause a "fussy" crystal to stop oscillating. A cog could also execute a COGSTOP instruction on the watchdog cog. There's not much else.

2) The simplest way would be for each cog to increment a LONG in hub memory. The watchdog cog would periodically compare a private copy of the counters to the ones in hub memory and make sure they don't match. It would then copy the new values over its copy.

3) Do a COGINIT on the cog forcing it to reset and reload its program.

4) There's a RESET bit in the clock mode value used for the CLKMODE instruction. If that's set, it forces the chip to reset just like the RST pin.

04-22-2008, 08:55 PM
Seems that it's quite feasible to have a cog "watching" other cogs as Mike describes but ultimately I think an external hardware watchdog is required. Could be as simple as a charging capacitor on the reset line that is periodically discharged by a pin driven from the watch dog before reset occurs. Until the watchdog itself fails that is...

For me, the past is not over yet.

04-23-2008, 01:12 AM
Funny you mention that. I've got an odd bug that I'm tracking in my thermostat code that causes a latch up anywhere
between 2 hrs and 60 hrs of run time. Since I can't afford for it to stop working while I'm not watching it I ran up a quick
hack to perform as a watchdog. The main line loop toggles a led at 0.5 hz (1s on / 1s off).. if it latches up this waits
~30 secs and reboots the chip. Works a treat.

'scuse the formatting. Just a quick left click / middle click from an xterm.. it's all good in the Propeller Tool.

'' WDT - Monitor a pin for change. No change in 30 s / reboot chip

PUB Start (Pin) : Ok
samples := 300 ' 300 samples
delay := clkfreq/10 ' 100msec
monitorpin := 1 << Pin ' Pin to watch for heartbeat
Ok := cognew(@WDT, 0)


WDT org
mov loop, samples
mov timer, cnt
add timer, delay
:main_loop waitcnt timer, delay

mov temp, ina
and temp, monitorpin
cmp temp, pinval wz
IF_Z jmp #:main_next

mov pinval, temp
mov loop, samples
jmp #:main_loop

:main_next sub loop, #1 wz
IF_Z jmp #Reset_chip
jmp #:main_loop

mov temp, #$80
clkset temp

'' Set in SPIN prior to cog bootup

samples long 0 ' Reload value for sample counter
delay long 0 ' Reload value for wait delay
monitorpin long 0 ' Mask for pin we are monitoring

'' Cog variables
timer long 0
loop long 0
pinval long 0
temp long 0

william chan
04-23-2008, 02:40 PM

Following your recommendation,
If I put a 0.1uF capacitor between the RST pin and ground, how long will the Propeller take to start-up from application of power?


www.fd.com.my (http://www.fd.com.my)
www.mercedes.com.my (http://www.mercedes.com.my)

04-23-2008, 11:13 PM
A capacitor direct to the pin is a bad idea for a watchdog. You are likely to suffer from a couple of "issues"

A) Adequate startup delay to get the chip running and ensuring it does not false trigger

B) Some way of disconnecting it while you program the chip

and my favourite

C) What if the watchdog cog locks up in a state that keeps the capacitor in a benign state?

A dedicated watchdog chip, or at least a 555 would be a better solution if you really have to go hardware.

I've hit my propeller with all sorts of horrible noise, bad power, invalid inputs and numerous other nasty things and found the processor itself to be
as close to rock solid as I've seen anywhere (read as I've never seen the hardware lockup/reboot without me inducing incredible amounts of noise into the reset pin directly -
- courtesy of 15M of cable between the prop clip and the proto board).
My code on the other hand can be slightly less reliable than the chip its running on.