Searching \ for '[PIC] Reset IC - how necessary? WDT Importance' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=port
Search entire site for: 'Reset IC - how necessary? WDT Importance'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Reset IC - how necessary? WDT Importance'
2004\10\26@181258 by Bob Axtell

face picon face
The PIC WDT actually makes the PIC almost bulletproof, and I ALWAYS
use it. I make sure that there is always just ONE clrwdt in the entire
program,
and it is placed at a point where I expect the PIC to be running
perfectly to
access it.

The PIC natural timeout is ~18ms. I  execute CLRWDT  every 10-15 ms, rarely
more often. I usually embed it inside a call that may check a few
critical items,
such as the state of the TRIS registers,  INTCON, SSPCON etc.

Its possible that the PIC itself gets forced into a state that only a
RESET can
make it recover. This is especially important when the PIC is running
near an
RF source, like a cellular modem, or is line-powered (lightning), or can be
affected by ESD.

While it IS a good idea to rewrite the TRIS resisters often (and I do), I am
suspicious when something causes a TRIS registers or INTCON to be in a
wrong state, and I see that as a signal that an ESD event ocurred- and
if I can,
I allow a WDT reset.

Another reason I like the WDT reset is that it allows a clean reset to occur
after bootloading new firmware. Allowing the WDT to timeout causes a
clean start.

--Bob

Peter L. Peres wrote:

{Quote hidden}

> ______________________________________________

2004\10\26@213513 by Spehro Pefhany

picon face
At 03:12 PM 10/26/2004 -0700, you wrote:
>The PIC WDT actually makes the PIC almost bulletproof, and I ALWAYS
>use it. I make sure that there is always just ONE clrwdt in the entire
>program,
>and it is placed at a point where I expect the PIC to be running perfectly to
>access it.
>
>The PIC natural timeout is ~18ms. I  execute CLRWDT  every 10-15 ms, rarely
>more often. I usually embed it inside a call that may check a few critical
>items,
>such as the state of the TRIS registers,  INTCON, SSPCON etc.

Too slow. With no prescaler you have to do it every 7 msec at a minimum,
probably
faster for wider temperature range. I think 5 msec (not counting prescaler) is
about right.

<other good comments snipped>

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com




____________________________________________

2004\10\27@014922 by Bob Axtell

face picon face
Spehro Pefhany wrote:

{Quote hidden}

For PICs other than the new INTRC versions, like the PIC16F88, etc, your
statement is
possibly correct, but for these new devices, the WDT is extremely
repeatable (tunable by
OSCTUNE) so are within 1-2 mS.

For the PIC16F88, the precise WDT time is 16.38 mS if OSCTUNE is used to
set the
oscillator. I can adjust that length with WDTCON, too.

> <other good comments snipped>

Thanks!

{Quote hidden}

I like your note "the journey...' .

--Bob

>
>
> ______________________________________________

2004\10\27@075635 by olin_piclist

face picon face
Bob Axtell wrote:
> While it IS a good idea to rewrite the TRIS resisters often (and I do),

A good idea in your opinion apparently.  Others here disagree.  I personally
find such tactics silly.

Exactly what failure are you trying to protect against?  If you're worried
about an ESD event or something flipping a bit, why is TRIS special?
Certainly many other bits in many other registers could cause havoc with
your program.  If you're worried about program memory flash bits getting
flipped, then the more bits your program uses the more vunerable it is.  The
extra code to check for a problem is actually be increasing the likelyhood
of encountering a problem.  If you're worried about buggy code then I submit
that adding more code may make the problem worse.  You would be better off
spending the time on more careful testing.  Overall, this approach sounds a
bit like not going on golf courses because you might get hit by lightning,
while routinely driving 20 miles on a busy highway.

Most applications can live with the very very low probability of such a
failure occurring.  Those truly mission critical applications that can't
accept this miniscule risk can't rely on the program to detect its own
failure anyway.  They require a separate external watchdog at least, one
that can independently verify some part of the operation and independently
cause a shutdown, restart, or whatever.

By the way, a 10F200 makes a great little external watchdog.  I'm working on
a project right now using one for this purpose (It's really not that mission
critical, but the managers have a medical devices background and just can't
give up the concept of a separate failsafe chip they can physically look
at).  The 10F drives the MCLR line of the main controller, and does the
timing and sequencing of the 3 inputs to know what state the unit is in and
when to release the main processor.  One of the inputs is a heartbeat signal
from the main processor, and the 10F is programmed to wait a certain while
after reset for the main processor to get past initialization, then require
a minimum pulse period on the heartbeat line.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\10\27@091645 by Spehro Pefhany
picon face
At 10:49 PM 10/26/2004 -0700, you wrote:


>For PICs other than the new INTRC versions, like the PIC16F88, etc, your
>statement is
>possibly correct, but for these new devices, the WDT is extremely
>repeatable (tunable by
>OSCTUNE) so are within 1-2 mS.

Ah, okay, I forgot they upgraded that on some new chips to run off the same
oscillator,
and with a 16-bit prescaler- with power-on value of 01000 for 16.38msec
nominal.
This makes very good sense. Some micros (PIC?) have an arrangement where
they can
switch to the internal RC oscillator in case of a failure of the
crystal/resonator
oscillator so they have a "limp home" type of capability- which should
noticeably
improve reliability.

There doesn't seem to be any guarantee of the uncalibrated WDT range
(T.B.D. on DS30487B) .

{Quote hidden}

Some days it's a more enjoyable journey than others. ;-) I like to travel,
and one of my favorite little books is one called "Bad Trips" - a compendium
of  anecdotes by various well-known people describing their worst trips. Bob
Geldof on the seamy backstreets of Bangok, English author Jonathan Raban
in Morgan City, LA and so on. ;-)

Of course the 'Journey' above is referring to  enjoying and getting the most
from the (sometimes painful) process, rather than always focusing on the
goals.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamKILLspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com




____________________________________________

2004\10\27@094252 by Spehro Pefhany

picon face
At 07:56 AM 10/27/2004 -0400, you wrote:
>Bob Axtell wrote:
> > While it IS a good idea to rewrite the TRIS resisters often (and I do),
>
>A good idea in your opinion apparently.  Others here disagree.  I personally
>find such tactics silly.
>
>Exactly what failure are you trying to protect against?  If you're worried
>about an ESD event or something flipping a bit, why is TRIS special?

Because some programmers set it (and other SFRs) just once, at the beginning
of a program! And then *hope* that 75 lightning storms and 2 years later the
value will not have changed! Some of us create products that have
to run 24/7 in industrial and other demanding applications. Just cutting
the power to reset a malfunctioning product is unacceptable and possibly
very, very costly (in dollars and reputation, and sometimes safety).

A typical control application involves reading inputs, calculating the
outputs, and repeating (vastly simplified, of course). In case of a
disruption, one or two or three control cycle(s) later most of the data is
re-calculated except perhaps for integral values.

Good hardware design should prevent this from happening very often, but
unlike in the EMC standards there is no REAL upper limit to external
noise. Even a very, very infrequent issue multiplied by a large number of
units in the field represents a significant problem. Most of us have suffered
inconvenience because of consumer products that just stopped functioning
until power was removed and re-applied or a hidden reset button was
pressed (I can think of half a dozen or more that I've seen do this).
This is unacceptable behavior in many applications. For example, if the
engine control computer on your car quit working until the battery was
disconnected and reconnected.. not nice at all. Contrary to
a somewhat common belief the energy required to disrupt a micro's
operation is orders of magnitude less than required to destroy the
part- so that excuse should not be used to ignore the issues.

>Certainly many other bits in many other registers could cause havoc with
>your program.  If you're worried about program memory flash bits getting
>flipped, then the more bits your program uses the more vunerable it is.

Flash has not proven to be a problem, at least with PICs (Knock On Wood).
If it was, I'd drop the micro like a hot potato.
I don't enable LV programming. Soft errors in registers are another matter.

>   The
>extra code to check for a problem is actually be increasing the likelyhood
>of encountering a problem.  If you're worried about buggy code then I submit
>that adding more code may make the problem worse.  You would be better off
>spending the time on more careful testing.  Overall, this approach sounds a
>bit like not going on golf courses because you might get hit by lightning,
>while routinely driving 20 miles on a busy highway.

Refreshing SFRs and especially DDRs (TRISx) is recommended procedure for
the kind of situation I mention. See Intel application notes, for example.
It's standard procedure. Also, IIRC, required for safety-critical
applications by the UL1998 standard.

>Most applications can live with the very very low probability of such a
>failure occurring.  Those truly mission critical applications that can't
>accept this miniscule risk can't rely on the program to detect its own
>failure anyway.  They require a separate external watchdog at least, one
>that can independently verify some part of the operation and independently
>cause a shutdown, restart, or whatever.

So you write WDT reset code that checks all the TRIS registers for
proper values before resetting the WDT? That's okay too (perhaps better).

{Quote hidden}

I don't like anything that complex for a WDT.  Too many possible
undesirable states. Maybe it's okay, but I'd want to analyze it a lot.
It would certainly need BOR.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam.....interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com




____________________________________________

2004\10\28@003429 by Bob Axtell

face picon face
Olin Lathrop wrote:

>Bob Axtell wrote:
>  
>
>>While it IS a good idea to rewrite the TRIS resisters often (and I do),
>>    
>>
>
>A good idea in your opinion apparently.  Others here disagree.  I personally
>find such tactics silly.
>
>  
>
Be careful, Olin, you're going off the reservation again. Apparently you
have no experience with
electronics operating near strong RF or ESD sources. The traces on the
PCB act as antennas unless
very careful hardware design is done. This issue is not a software
problem, but the effects might SEEM
to be so. My experience with this came from Motorola HC05 designs before
MC came along. The port
latches -being near the pins themselves, I guess- changed rather easily
under a strong RF field. If anybody
still designs with these things, try it and see.

Personally, I have never seen such a problem with PICs, but then again,
many of my signals are bypassed
with 100pF ceramic caps or even LC filters between points on the PCB. I
deliberately prevent PIC pins
from picking up a signal so I can key a long-range radio with the
antenna a few inches away and nothing
happens. One design I am testing now has a cellular modem mounted on the
same PCB as the PIC
and its antenna is 2" away from the PCB.  I maintain two copies of every
critical register, and maintain 3 sets
of EEPROM Data Configuration bits; the copies are matched to the
originals every 12mS; I force a reset if it
won't cause a problem immediately, or I set a flag to force a reset at
the first opportunity.

>Exactly what failure are you trying to protect against?  If you're worried
>about an ESD event or something flipping a bit, why is TRIS special?
>  
>
TRIS are easy to check so I threw it out as a suggestion. I actually
check many more. It also follows my
thoughts that in an ESD or RF situation, the port pins and latches are
most exposed.

{Quote hidden}

Absurd conclusion, Olin. You know better. ESD is- and always was- a
hardware problem, not a
software one.

>Most applications can live with the very very low probability of such a
>failure occurring.  Those truly mission critical applications that can't
>accept this miniscule risk can't rely on the program to detect its own
>failure anyway.  They require a separate external watchdog at least, one
>that can independently verify some part of the operation and independently
>cause a shutdown, restart, or whatever.
>
>  
>
Apparently you don't understand how a WDT is used. You need to keep up.

{Quote hidden}

I agree, that is a good idea. I've trying to use one of these for
something else, but this is good.

Soften your tone, Olin. I didn't just fall off the turnip truck. Listen,
you might learn something.

--Bob

>*****************************************************************
>Embed Inc, embedded system specialists in Littleton Massachusetts
>(978) 742-9014, http://www.embedinc.com
>_____________________________________________

2004\10\28@005517 by Bob Axtell

face picon face
Spehro Pefhany wrote:

{Quote hidden}

Ya know, since I stopped designing with crystals and switched to ceramic
resonators,
I haven't had a single oscillator failure. Mine were caused by shock
(broken crystals)
when somebody hit a bump in a 100MPH chase. I'll never use another
crystal unless
it is absolutely necessary.


> There doesn't seem to be any guarantee of the uncalibrated WDT range
> (T.B.D. on DS30487B)

That's correct. You have to load OSCTUNE at startup to get a reliable WDT.


> .
> Some days it's a more enjoyable journey than others. ;-) I like to
> travel,
> and one of my favorite little books is one called "Bad Trips" - a
> compendium
> of  anecdotes by various well-known people describing their worst
> trips. Bob
> Geldof on the seamy backstreets of Bangok, English author Jonathan Raban
> in Morgan City, LA and so on. ;-)
>
I've been to 36 countries, loved every minute. But I can't go anymore,
too many
health issues. I'll be a doctor in my next life though; this engineering
stuff didn't
allow me to hit easy street.

> Of course the 'Journey' above is referring to  enjoying and getting
> the most
> from the (sometimes painful) process, rather than always focusing on
> the goals.
>
Well spoken.

--Bob

{Quote hidden}

> ______________________________________________

2004\10\28@011053 by Scott Dattalo

face
flavicon
face
On Wed, 27 Oct 2004, Bob Axtell wrote:

{Quote hidden}

Bob,

At Synaptics, we do the 'rewrite tris bit' 30-million times per year.
That's about how many TouchPads + iPods + other capacitance sensing gizmos
we ship each year. The main reason is to ensure that the integrity of the
I/O's are maintained. Our devices are not PICs, but like most processors,
the output latches are necessarily electrically close to the I/O pins and
very susceptible to ESD disturbances. Our devices are specifically
designed to be touched. We try not to descriminate against overly charged
people (either electrically or personality :). So a 15kV human-body model
zap on to the surface of TouchPad might cause the TouchPad to reset, but
seldom will phase the I/O's. The host may not even notice!

Scott
____________________________________________

2004\10\28@033319 by Rob Hamerling

flavicon
face


Bob Axtell wrote:

> You have to load OSCTUNE at startup to get a reliable WDT.

Bob,

Could you please clarify this a bit, since I'm beginning to doubt if I
understand this aspect of the 16F87/88. The datasheet tells me that the
oscillator is factory tuned, but can be adjusted in the application by
changing OSCTUNE. So I assumed that I need to write to OSCTUNE register
_only_ when I want a different frequency than the calibrated value.
But you seem to tell me that I need to write to OSCTUNE _always_ to get
a reliable WDT.

Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/
____________________________________________

2004\10\28@061723 by Bob Ammerman

picon face

----- Original Message -----
From: "Olin Lathrop" <olin_piclistspamspam_OUTembedinc.com>
To: "Microcontroller discussion list - Public." <@spam@piclistKILLspamspammit.edu>
Sent: Wednesday, October 27, 2004 7:56 AM
Subject: Re: [PIC] Reset IC - how necessary? WDT Importance


> Bob Axtell wrote:
>> While it IS a good idea to rewrite the TRIS resisters often (and I do),
>
> A good idea in your opinion apparently.  Others here disagree.  I
> personally
> find such tactics silly.
>
> Exactly what failure are you trying to protect against?  If you're worried
> about an ESD event or something flipping a bit, why is TRIS special?

Maybe because a flipped TRIS bit can result in hardware damage??

Bob Ammerman
RAm Systems

____________________________________________

2004\10\28@131322 by Bob Axtell

face picon face
I am wrong about this. Its already factory-set, no tweaking needed.
I wonder how accurate it is?

Thanks, Rob, good catch.

--Bob


Rob Hamerling wrote:

{Quote hidden}

--
Note: Attachments must be sent to
KILLspamattachKILLspamspamengineer.cotse.net, and
MAY delay replies to this message.
       520-219-2363

____________________________________________

2004\10\28@140427 by Jan-Erik Soderholm

face picon face
Bob Axtell wrote :

> I am wrong about this. Its already factory-set, no tweaking needed.

Generaly speaking (if I'm not totaly wrong) that is the
difference between OSCTUNE and (the old) OSCCAL.

Jan-Erik.


{Quote hidden}

____________________________________________

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...