Post by thread:[PIC] Reset IC - how necessary? WDT Importance

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}> On Mon, 25 Oct 2004, James A wrote: > >> I am using a PIC with startup delay, brown-out detect and watch-dog, >> in a >> $100 consumer item powered by a wall-wart and 7805. How necessary is >> it to >> also include a reset IC for starting up the PIC cleanly? The PIC is >> going to >> control the rest of the other ICs, so it's just the PIC. >> >> For your info, the unit is likely to be running all the time, 24/7 >> 365 days >> per year (mainly in the unit's standby mode, but the PIC will be >> running all >> that time too). >> >> We are going to make about 1000 of them, and this is the first time I've >> made more than about 100 of anything, and have not used reset ICs in the >> past. Like most consumer entertainment items, it is not critical that it > > > Plan for 1-3% failure rate in production (in despite of material > quality control). > >> never crashes/starts up, but would be nice to avoid it if >> cost-effective to >> do so. The prices of reset ICs that I've seen are comparable to a PIC >> itself >> (unless someone can recommend a cheap one), so if it is going to >> cause one >> problem in 10k, I am tempted to leave it out. > > > You can arrange your code to hawe the wdt running *and* time out > deliberately (i.e. never run the clrwdt instruction in the idle loop, > or better, never use it at all). You only use clrwdt when executing a > task that should not be interrupted, and only at its start. I have > used this method and it is nearly impossible to hang the pic when > using it. It is equivalent to having a reset every 2.x seconds all the > time. Obviously this cannot be used for more advanced programs but it > is perfect for the simple buttons-sensors-leds-and-relays minder > applications I have used it for. > > Peter > > > ______________________________________________

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_OUTspeffTakeThisOuTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com ____________________________________________

Spehro Pefhany wrote: {Quote hidden}> 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. > 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}> > > Best regards, > > Spehro Pefhany --"it's the network..." "The Journey is the > reward" > .....speffKILLspam@spam@interlog.com Info for manufacturers: > http://www.trexon.com > Embedded software/hardware/analog Info for designers: > http://www.speff.com > > I like your note "the journey...' . --Bob > > > ______________________________________________

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 ____________________________________________

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}>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! >>Best regards, >>Spehro Pefhany --"it's the network..." "The Journey is the reward" >I like your note "the journey...' . > >--Bob 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" speffKILLspaminterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com ____________________________________________

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}>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. 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" .....speffKILLspam.....interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com ____________________________________________

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}>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. > > 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}>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. > > > 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 >_____________________________________________

Spehro Pefhany wrote: {Quote hidden}> 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. > 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}> Best regards, > > Spehro Pefhany --"it's the network..." "The Journey is the > reward" > EraseMEspeffspam_OUTTakeThisOuTinterlog.com Info for manufacturers: > http://www.trexon.com > Embedded software/hardware/analog Info for designers: > http://www.speff.com > > > > > ______________________________________________

On Wed, 27 Oct 2004, Bob Axtell wrote: {Quote hidden}> 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. 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 ____________________________________________