Is a watchdog timer appropriate in a radio?

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

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

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.

"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.

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/
********************************************************************

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.

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

"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 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:

> 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/
********************************************************************