Post by thread:[PIC] Microcontroller Reliability ?

Hello all, I am new to microcontrollers and I am about to start learning with the microchip PIC1 Flash Starter Kit. Eventually I hope to complete a project I have in mind but I have a question about the stability of the running code. I am concerned that the pic's will need the occasional reset. The project that I am working on will monitor sensor inputs and output TTL logic based on those inputs. I need it to run 24 hours a day, 7 days a week with no worries that the pic has hung up and is in need of a reset. I realize that poorly written code may/will contribute to problems but assuming the code is perfect, how often do microcontrollers in general need to go thru a power cycle or be reset? Thanks... -- View this message in context: www.nabble.com/-PIC-Microcontroller-Reliability--t1159255.html#a3042826 Sent from the MicroControllers - PIC forum at Nabble.com.

I'm sure you'll get better answers from the more experienced members on the list but I'll give it a shot. The PICs have a "watchdog timer" feature, which you can optionally enable, that constantly counts down outside your program control. If the timer gets to 0, it assumes something has gone wrong and automatically resets the PIC. You have to make sure you reset the timer in your code before it has a chance to get to 0, so as long as your code is running smoothly, the timer never gets to 0. Jason From: "mchristisen" <spam_OUTmchristisenTakeThisOuTsas.samsung.com> Sent: Monday, February 20, 2006 6:16 PM {Quote hidden}> > I am new to microcontrollers and I am about to start learning with the > microchip PIC1 Flash Starter Kit. Eventually I hope to complete a project > I > have in mind but I have a question about the stability of the running > code. > I am concerned that the pic's will need the occasional reset. > > The project that I am working on will monitor sensor inputs and output TTL > logic based on those inputs. I need it to run 24 hours a day, 7 days a > week > with no worries that the pic has hung up and is in need of a reset.

On 20 Feb 2006, at 18:16, mchristisen wrote: >Eventually I hope to complete a project I > have in mind but I have a question about the stability of the running code. > I am concerned that the pic's will need the occasional reset. > > The project that I am working on will monitor sensor inputs and output TTL > logic based on those inputs. I need it to run 24 hours a day, 7 days a week > with no worries that the pic has hung up and is in need of a reset. > > I realize that poorly written code may/will contribute to problems but > assuming the code is perfect, how often do microcontrollers in general need > to go thru a power cycle or be reset? The problem is not with the microprocessor - write a one (or two) line looping program, give it a perfect power supply and put it in a screened room unconnected to anything else and it will (probably) work longer than you. The problem is the program bugs, the power supply failures (off/dip/spike), and the external interference and ESD. If the program is perfect that only leaves you to worry about a filtered supply with a backup system. All inputs and outputs will be galvanically isolated. Or you could just use the watchdog timer to reset when something goes wrong. George Smith

{Quote hidden}>-----Original Message----- >From: .....piclist-bouncesKILLspam@spam@mit.edu [piclist-bouncesKILLspammit.edu] >Sent: 21 February 2006 02:17 >To: .....piclistKILLspam.....mit.edu >Subject: [PIC] Microcontroller Reliability ? > > > >Hello all, > >I am new to microcontrollers and I am about to start learning >with the microchip PIC1 Flash Starter Kit. Eventually I hope >to complete a project I have in mind but I have a question >about the stability of the running code. >I am concerned that the pic's will need the occasional reset. > >The project that I am working on will monitor sensor inputs >and output TTL logic based on those inputs. I need it to run >24 hours a day, 7 days a week with no worries that the pic has >hung up and is in need of a reset. > >I realize that poorly written code may/will contribute to >problems but assuming the code is perfect, how often do >microcontrollers in general need to go thru a power cycle or be reset? Excluding poorly written/buggy code then virtualy never, unless some there has been some external disturbance such as a power glitch, radiated interference etc. PICs don't run complex, bloated operated system like Linux or Windows and don't have to simultaneously run numerous programs of dubious origin, just the one that was written by you. If you want good reliability, you have to write your code with that in mind, ensuring that all loops that could potentialy get stuck have timeouts etc. and that you use the watchdog timer in a proper manner. Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. =======================================================================

At 06:16 PM 2/20/2006 -0800, you wrote: >Hello all, > >I am new to microcontrollers and I am about to start learning with the >microchip PIC1 Flash Starter Kit. Eventually I hope to complete a project I >have in mind but I have a question about the stability of the running code. >I am concerned that the pic's will need the occasional reset. > >The project that I am working on will monitor sensor inputs and output TTL >logic based on those inputs. I need it to run 24 hours a day, 7 days a week >with no worries that the pic has hung up and is in need of a reset. > >I realize that poorly written code may/will contribute to problems but >assuming the code is perfect, how often do microcontrollers in general need >to go thru a power cycle or be reset? Depends totally on the conditions. You'll virtually never see a commercial design that doesn't include a hidden reset button or other means to do a hard reset. Of course you'll make your code perfect, use at least one watchdog timer, do "sanity checks" on everything volatile, refresh everything volatile, and make your hardware very EMI resistant, but there's no limit to outside disturbances in some situations (eg. lightning strikes), so it's always *possible* that an upset could put the part into an undesirable state (of which there are quite a few in most micro designs, lots of bits that could be flipped). In 'mission critical' applications you may well need to add redundancy or external hardware to make sure things don't get out of hand. This is not a trivial issue, it can require real engineering. >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 ->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff

At 04:04 PM 2/21/2006 -0800, you wrote: >Make sure that the code to clear/reset the watchdog timer is not in the >interrupt routines, as you could have main body of code hung and still do >good interrupts. > >Bill That's the conventional wisdom, but there are exceptions where it is better to use even a periodic interrupt, and communicate via flags or counters to the interrupt routine. You should read this advice as "don't *simply* reset the WDT in a periodic interrupt routine". Similarly, *simply* resetting the WDT in a main routine does not guarantee that the interrupts are still occurring (which could be as bad or worse). Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" speffspam_OUTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com ->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff

> -----Original Message----- > From: @spam@piclist-bouncesKILLspammit.edu > [KILLspampiclist-bouncesKILLspammit.edu] On Behalf Of Spehro Pefhany > Sent: Tuesday, February 21, 2006 8:20 PM > To: Microcontroller discussion list - Public. > Subject: Re: [PIC] Microcontroller Reliability ? > >>I realize that poorly written code may/will contribute to problems but >>assuming the code is perfect, how often do microcontrollers in general >>need to go thru a power cycle or be reset? > > Depends totally on the conditions. You'll virtually never see > a commercial design that doesn't include a hidden reset button > or other means to do a hard reset. Does cycling the power count as one method of "hard reset"? I guess that is the ultimate means to reset. ;-) I've had some strange experience with my PC lately. I need to power down the PC completely so that the network card can get an valid IP address from the router using DHCP after rebooting from Linux to Windows. I sometimes also need to power down the PC so that PICkit 2 can talk to the PICs reliably again after issuing some strange commands to PICkit 2 under Linux. Simply reset won't work. I still do not know what is happening. Regards, Xiaofan

----- Original Message ----- From: "Bill & Pookie" <RemoveMEreddxTakeThisOuTcomcast.net> To: "Microcontroller discussion list - Public." <spamBeGonepiclistspamBeGonemit.edu> Sent: Tuesday, February 21, 2006 7:04 PM Subject: Re: [PIC] Microcontroller Reliability ? > Make sure that the code to clear/reset the watchdog timer is not in the > interrupt routines, as you could have main body of code hung and still do > good interrupts. Or vica-versa. You really want to make sure that all the critical parts of your program are executing. To do this I create a global variable, perhaps called wdflgs. Then in a my timer interrupt I include code like: movf wdflgs,w skpz goto continue clrwdt ; THIS IS THE ONLY CLRWDT IN THE PROGRAM! movlw <bits for all activities that should be happening> movwf wdflgs ;Note: you can even conditionally turn on bits here for actions that are not always in progress. ;For example, if the data-ready bit is set in the UART you can set a bit that will be cleared when that character is processed. btfs<s,c> somereg,somebit bsf wdflgs,someflagbit continue: Then at appropriate points in your code insert: bcf wdflgs,someflagbitoranother This method insures that all the critical routines are getting called, Bob Ammerman RAm Systems

> -----Original Message----- > From: TakeThisOuTpiclist-bouncesEraseMEspam_OUTmit.edu [RemoveMEpiclist-bouncesTakeThisOuTmit.edu] On Behalf > Of Spehro Pefhany > Sent: Tuesday, February 21, 2006 7:36 PM > To: Microcontroller discussion list - Public. > Subject: Re: [PIC] Microcontroller Reliability ? > > At 04:04 PM 2/21/2006 -0800, you wrote: > >Make sure that the code to clear/reset the watchdog timer is not in the > >interrupt routines, as you could have main body of code hung and still do > >good interrupts. > > > >Bill > > That's the conventional wisdom, but there are exceptions where it is > better > to use even a periodic interrupt, and communicate via flags or counters to > the interrupt routine. You should read this advice as "don't *simply* > reset > the WDT in a periodic interrupt routine". > > Similarly, *simply* resetting the WDT in a main routine does not guarantee > that the interrupts are still occurring (which could be as bad or worse). > > Best regards, > I've sometimes had the watchdog petting in an ISR but it would look at a set of flag bits to decide whether to pet the dog. The ISR would read the bits and check for all being set. If all set it would pet the dog and clear the flags. If anyone flag was not set the ISR did not pet the dog. You could use a flag bit for each task or isr you are concerned with. ------------------------------------- Notice of Confidentiality ---------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmasterEraseME.....vgt.net. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

> -----Original Message----- > From: EraseMEpiclist-bouncesmit.edu [RemoveMEpiclist-bouncesEraseMEEraseMEmit.edu] On Behalf {Quote hidden}> Of Chen Xiao Fan > Sent: Tuesday, February 21, 2006 7:51 PM > To: Microcontroller discussion list - Public. > Subject: RE: [PIC] Microcontroller Reliability ? > > > > > -----Original Message----- > > From: RemoveMEpiclist-bouncesspam_OUTKILLspammit.edu > > [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu] On Behalf Of Spehro Pefhany > > Sent: Tuesday, February 21, 2006 8:20 PM > > To: Microcontroller discussion list - Public. > > Subject: Re: [PIC] Microcontroller Reliability ? > > > >>I realize that poorly written code may/will contribute to problems but > >>assuming the code is perfect, how often do microcontrollers in general {Quote hidden}> >>need to go thru a power cycle or be reset? > > > > Depends totally on the conditions. You'll virtually never see > > a commercial design that doesn't include a hidden reset button > > or other means to do a hard reset. > > Does cycling the power count as one method of "hard reset"? > I guess that is the ultimate means to reset. ;-) > > I've had some strange experience with my PC lately. I need to > power down the PC completely so that the network card can get > an valid IP address from the router using DHCP after rebooting > from Linux to Windows. I sometimes also need to power down the > PC so that PICkit 2 can talk to the PICs reliably again after > issuing some strange commands to PICkit 2 under Linux. Simply > reset won't work. I still do not know what is happening. Try opening a cmd window when you start windows. See if "ipconfig /release" followed by "ipconfig /renew" works. The router may have sent the address to Linux but windows starting did not do that release of the previously stored IP address but instead might have just sought an address and got ignored effectively because the router thought it already had one. Might not work... ------------------------------------- Notice of Confidentiality ---------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify EraseMEpostmasterspamspamBeGonevgt.net. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

> -----Original Message----- > From: RemoveMEpiclist-bouncesKILLspammit.edu [piclist-bouncesSTOPspamspam_OUTmit.edu] On Behalf {Quote hidden}> Of Robert Ammerman > Sent: Wednesday, February 22, 2006 1:27 AM > To: Microcontroller discussion list - Public. > Subject: Re: [PIC] Microcontroller Reliability ? > > > ----- Original Message ----- > From: "Bill & Pookie" <spamBeGonereddxSTOPspamEraseMEcomcast.net> > To: "Microcontroller discussion list - Public." <KILLspampiclistspamBeGonemit.edu> > Sent: Tuesday, February 21, 2006 7:04 PM > Subject: Re: [PIC] Microcontroller Reliability ? > > > > Make sure that the code to clear/reset the watchdog timer is not in the > > interrupt routines, as you could have main body of code hung and still > do > > good interrupts. > > Or vica-versa. > > You really want to make sure that all the critical parts of your program > are > executing. > > To do this I create a global variable, perhaps called wdflgs. Then in a my {Quote hidden}> timer interrupt I include code like: > > movf wdflgs,w > skpz > goto continue > > clrwdt ; THIS IS THE ONLY CLRWDT IN THE PROGRAM! > movlw <bits for all activities that should be happening> > movwf wdflgs > > ;Note: you can even conditionally turn on bits here for actions that are > not > always in progress. > ;For example, if the data-ready bit is set in the UART you can set a bit {Quote hidden}> that will be cleared when that character is processed. > > btfs<s,c> somereg,somebit > bsf wdflgs,someflagbit > > continue: > > > > Then at appropriate points in your code insert: > > bcf wdflgs,someflagbitoranother > > This method insures that all the critical routines are getting called, > > Bob Ammerman > RAm Systems So apparently I'm not the only one to do this and my other post was redundant. Yeah it works... ------------------------------------- Notice of Confidentiality ---------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify EraseMEpostmasterEraseMEvgt.net. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.