Paul E. Bennett wrote:

> Kevin D. Quitt wrote:
> 
>> On Mon, 11 Apr 2005 14:08:24 GMT, Michael <NoSpam@att.net> wrote:
>>>Which is why it's a good idea to make that watchdog hardware untouchable
>>>by
>>>programmers.  In the case I cited, the watchdog implemented as little
>>>more than a binary counter and a bit of glue.
>> 
>> Something has to feed the dog cookies to keep it from going off.  This is
>> usually something in the idle loop of the OS or application.  Where this
>> code is, and exactly how it works isn't something for a novice to decide.
>> If the status of the system can be verified externally, that's much
>> better.

Sorry about that. I seemed to have hit the send key when the phone rang. 
I'll pick up where I left off.
 
> I consider that the output to kick the watchdog should only be proferred
> when the complete set of sanity checks of the system operation have proved
> to be in the "sane system" region. For me that means really reading its
> inputs, still in control of its outputs and having no other detectable
> errors. I use a pulse maintained relay circuit that is wired to drop 
output power if the state of its input is not inverted at regular 
intervals. The circuit is configured such that any single component failure 
is almost certain of achieving the outputs powered down state.


-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************

Kevin D. Quitt wrote:

> On Mon, 11 Apr 2005 14:08:24 GMT, Michael <NoSpam@att.net> wrote:
>>Which is why it's a good idea to make that watchdog hardware untouchable
>>by
>>programmers.  In the case I cited, the watchdog implemented as little more
>>than a binary counter and a bit of glue.
> 
> Something has to feed the dog cookies to keep it from going off.  This is
> usually something in the idle loop of the OS or application.  Where this
> code is, and exactly how it works isn't something for a novice to decide.
> If the status of the system can be verified externally, that's much
> better.

I consider that the output to kick the watchdog should only be proferred 
when the complete set of sanity checks of the system operation have proved 
to be in the "sane system" region. For me that means really reading its 
inputs, still in control of its outputs and having no other detectable 
errors. I use a pulse maintained relay circuit tha
 

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************

On Mon, 11 Apr 2005 14:08:24 GMT, Michael <NoSpam@att.net> wrote:
>Which is why it's a good idea to make that watchdog hardware untouchable by
>programmers.  In the case I cited, the watchdog implemented as little more than
>a binary counter and a bit of glue.

Something has to feed the dog cookies to keep it from going off.  This is
usually something in the idle loop of the OS or application.  Where this
code is, and exactly how it works isn't something for a novice to decide.
If the status of the system can be verified externally, that's much
better.  


-- 
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
  Per the FCA, this address may not be added to any commercial mail list

"Kevin D. Quitt" wrote:
(snip)
> Further, hardware watchdogs are frequently rendered impotent by programmer
> putting the code to tickle the dog in an interrupt routine.
> 
> --
>  _
> Kevin D. Quitt                                    Kevin@Quitt.net


Which is why it's a good idea to make that watchdog hardware untouchable by
programmers.  In the case I cited, the watchdog implemented as little more than
a binary counter and a bit of glue.

On Sat, 09 Apr 2005 05:10:51 GMT, Michael <NoSpam@att.net> wrote:
>"bad idea to depend on a hardware watchdog" ... hardware as opposed to what?
>Perhaps you meant to say, "bad idea to depend on any watchdog".

From a system standpoint, there is no such thing as a reliable "software"
watchdog; since reliability is key to the definition of watchdog, there is no
such thing as a software watchdog.

Further, hardware watchdogs are frequently rendered impotent by programmer
putting the code to tickle the dog in an interrupt routine.

--
 _
Kevin D. Quitt					  Kevin@Quitt.net
	      96.37% of all statistics are made up

Paul E. Bennett wrote:
> Neil Kurzman wrote:
>
> >
> >
> > Gerald Bonnstetter wrote:
>
> [%X]
>
> >> Am I all wet thinking that way?  ;-)
> >>
> >>     Gerald Bonnstetter             Bonnsoft
> >
> > The designer did not think so.
> > A watch dog does not help CMOS latch up,  It is not a cure all.
>
> No, it is not a wet idea. Also, any watchdog that causes the power to

> completely recycle will resolve a latch-up problem (unless the gate
is
> truly blown). To me, it is better to expend an extra dime in order to

> ensure the dependability of a product. Of course, I am not in the
cheap toy
> development market.

We once made unmanned equipments located 400 km away, accessible by
tracks only, with reliability constraints, so the watch dog was
rather handy when an unknown bug tripped the system.
But we took care to detect and avoid high frequency watch dog resets.

Neil Kurzman wrote:

> 
> 
> Gerald Bonnstetter wrote:
 
[%X]

>> Am I all wet thinking that way?  ;-)
>>
>>     Gerald Bonnstetter             Bonnsoft
> 
> The designer did not think so.
> A watch dog does not help CMOS latch up,  It is not a cure all.

No, it is not a wet idea. Also, any watchdog that causes the power to 
completely recycle will resolve a latch-up problem (unless the gate is 
truly blown). To me, it is better to expend an extra dime in order to 
ensure the dependability of a product. Of course, I am not in the cheap toy 
development market.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************

"Kevin D. Quitt" wrote:
> 
> It is always a bad idea to depend on a hardware watchdog.  That being
> said, if there are no *known* bugs, the use of a 'dog is perfectly ok - as
> long as it's guaranteed to truly reset the entire system (preferably by
> cutting power for a time, rather than just toggle the processor's reset
> line).  There are power-controller chips that will do the power control
> when their reset line is hit, but this costs an extra dime or so...
> 
> --
> #include <standard.disclaimer>
>  _
> Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
>   Per the FCA, this address may not be added to any commercial mail list


"bad idea to depend on a hardware watchdog" ... hardware as opposed to what?
Perhaps you meant to say, "bad idea to depend on any watchdog".  But if what you
meant is that a software watchdog is preferable to a hardware watchdog, then I
strongly disagree.  Depending on a micro to always determine when it's lost and
take appropriate action can be asking for trouble.

A designer once asked me to critique his interface card that would connect a new
line printer to mainframe computers.  The interface spec. of the computers that
the new printer would ultimately attach to clearly stated that an I/O device
must inform the computer - by way of raising a special wire on the interface -
whenever the device is attached to the computer bus and supposedly operating but
is hopelessly broken.  Citing cost, The Powers nixed the designer's idea to use
an external (to the micro) hardware counter whose purpose would be to raise that
error signal.  The designer was very unhappy about this and I supported him. 
When the printer came to me for its Alpha attachment test some months later,
what do you suppose was the very first "show stopper" problem I wrote up?  The
darned printer often accepted commands and stayed logically attached, went off
to never-never-land because it's firmware sucked, and, being logically attached
to my channel (computer's interface), preempted every other device on that
interface.  I had to stop my test.  I saw that printer on my raised floor again
but only after Development had spent four precious months cramming in the
hardware counter that should have been in the original design.

Gerald Bonnstetter wrote:

> I guess it pays to assume anything could have an micro controller now days.
>
> The other day my truck's radio went blank (after some self induced
> frequency changes).  Ironically, I was on the way to the car dealer and
> less than a mile away.  ;-)
>
> Turning the truck off and then back on didn't change anything.  Because
> I was just taking the truck in for a unscheduled oil change, I made a
> quick check under the hood to make sure there were no obvious melted
> wires or smoke.  Seeing nothing wrong, I warned the service people and
> said I'd look at the radio myself later after they changed the oil.
>
> At home I found the fuse was good and it had full voltage on.  It also
> had about 2 volts on the radio side of the fuse while the fuse was removed.
>
> I looked and didn't see an easy way to get to the radio in the dashboard
> so I was planning to take it in to get it fixed.
>
> Luckily I didn't get the dealership called the next day and I decided I
> really should make sure I had done everything I could.  I hadn't done a
> "power down clear" on the radio to reset any micro controller that might
> be in the radio.  That 2 volts on the wire going to the radio made me
> suspect that there could be another power line leading to the radio.
>
> Not having a schematic of the truck's wiring, I used the brute force
> method and disconnected the battery for 30 seconds.  Thats all it took
> to fix it (so far).  It was raining the day it failed and there was some
> lightning in the area.  So hopefully it was a one time problem.
>
> I'm new to embedded design idea's (at home projects so far) so I'm
> thinking a watchdog timer would have been one way to have this problem
> fix itself easier than disconnecting the battery.  I have read some of
> the previous discussions and agree with the idea that if a watchdog
> timer is actually tripping, it means you messed up somewhere.  But it
> also seems like the user should have a reliable device.  So if in the
> field, a watchdog timer covers up a once in four year glitch.  Thats not
> all bad from my user's point of view.
>
> Am I all wet thinking that way?  ;-)
>
>     Gerald Bonnstetter             Bonnsoft

The designer did not think so.
A watch dog does not help CMOS latch up,  It is not a cure all.

It is always a bad idea to depend on a hardware watchdog.  That being
said, if there are no *known* bugs, the use of a 'dog is perfectly ok - as
long as it's guaranteed to truly reset the entire system (preferably by
cutting power for a time, rather than just toggle the processor's reset
line).  There are power-controller chips that will do the power control
when their reset line is hit, but this costs an extra dime or so...

-- 
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
  Per the FCA, this address may not be added to any commercial mail list