Post by thread:[PICLIST] Why Noises Change Register Values? How t

Hi all, I am a newbie of this mailing. A question has been puzzling me and I want to get some answers. I am a programmer writing software for microchips. I just wrote one for a product. When the engineers started testing it with noises and sparks of voltages, the software failed. I debugged the software and found that the noises caused the interrupt routine stop running, as if the T0IE had been reset to clear. I then wrote a routine to watch the interrupt; if it stops running I will use watchdog to restart the whole program. That works fine. Thus also proved that the noises did cause the interrupt stop running. Now this is my question: Can someone explain to me why the noises can change the value of the registers of the program? If it can change T0IE, what else would it change? I can't monitor all the variables; the thought that the noises can change values arbitrarily is very scary. It could be a disaster. Someone suggested me reset the program periodically. (For example, use watchdog and alike.) If so, is this a common practice that should be used on all projects? I believe there is some official guidance on this matter. Can someone enlighten me? Thanks alot!! Tony Pan -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

>Now this is my question: Can someone explain to me why the noises can >change the value of the registers of the program? If it can change T0IE, >what else would it change? I can't monitor all the variables; the thought >that the noises can change values arbitrarily is very scary. It could be a >disaster. This is called Electromagnetic Upset. There are seveeral possibilities as to the exact mechanism, but the end is the same. During the read, enough energy was received on the bus to either corrupt the location being read (trying to read $0000, but read $0032 instead) or to corrupt the data ($0000 was $AA, but I got $25). The only cure is to prevent this energy from reaching the micro. PCB layout is a major factor. Also power supply decoupling. Shielding is also helpful, but do the rest first. There is a lot you can do, but without seeing your exact schematic and PCB, it's hard to say exactly. -- Dave's Engineering Page: http://www.dvanhorn.org Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

>Thank you for the reply. Do you have a link pointing to an authoritative >document on what to do (or not to do) to protect the chip? There are too many books about it. I would recommend you just two, easy to read and understand: Ott, Henry W.: Noise Reduction Techniques in Electronic Systems Williams, Tim: Emc for Product Designers From this two books are written all application sheets for Motorola, Atmel and others. Andrej _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Ott book is very nice and I found in Burr-brown site a DesignSem3.pdf (649k) that complements it : is the best and ... free. Fernando Andy Jancura wrote: {Quote hidden}> >Thank you for the reply. Do you have a link pointing to an authoritative > >document on what to do (or not to do) to protect the chip? > > There are too many books about it. I would recommend you just two, easy to > read and understand: > > Ott, Henry W.: Noise Reduction Techniques in Electronic Systems > Williams, Tim: Emc for Product Designers > > >From this two books are written all application sheets for Motorola, Atmel > and others. > > Andrej > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

At 04:46 PM 3/8/01 -0500, Tony Pan wrote: >Thank you for the reply. Do you have a link pointing to an authoritative >document on what to do (or not to do) to protect the chip? You can search on EMI and "electromagnetic upset", but you're not going to find anything like a "cookbook" approach. You need a bit of understanding as to how this works, how the energy gets coupled into your circuits, then you do whatever you can to ruin that coupling. -- Dave's Engineering Page: http://www.dvanhorn.org Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

At 10:57 AM 3/27/01 -0500, you wrote: >At 04:46 PM 3/8/01 -0500, Tony Pan wrote: >>Thank you for the reply. Do you have a link pointing to an authoritative >>document on what to do (or not to do) to protect the chip? > >You can search on EMI and "electromagnetic upset", but you're not going to >find anything like a "cookbook" approach. >You need a bit of understanding as to how this works, how the energy gets >coupled into your circuits, then you do whatever you can to ruin that >coupling. I'd suggest reading _Noise Reduction Techniques in Electronic Systems_ (Ott) pretty much cover-to-cover, and after you've done that, review the relevant application notes from each of the major manufacturers of microcontrollers. There are also software techniques for dealing with errors that do occur and doing reasonable and safe (as possible) things after such an upset. Things like regularly refreshing the values on SFRs (not just once at power up). This is mostly a HARDWARE issue, but you can do things that will improve things for an OCCASIONAL upset. The "real" solution is to improve the hardware, and that's an analog EE task. If your software is safety-critical, see the relevant standards (eg. UL1998) and most likely get some outside advice on meeting the requirements. The methods used to keep internal noise from getting out also keep external noise from getting in, so you can also look for "EMC", a term which covers both sides of the issue. It's not a simple subject, and even (especially?) the most experienced of us have wrestled with it from time to time, especially in electrically hostile environments (as your arcing and sparks imply). 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 Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestKILLspammitvma.mit.edu

Please search in http://www.burr-brown.com site for DesignSem3.pdf. Is more than a cookbook. Fernando David VanHorn wrote: {Quote hidden}> At 04:46 PM 3/8/01 -0500, Tony Pan wrote: > >Thank you for the reply. Do you have a link pointing to an authoritative > >document on what to do (or not to do) to protect the chip? > > You can search on EMI and "electromagnetic upset", but you're not going to > find anything like a "cookbook" approach. > You need a bit of understanding as to how this works, how the energy gets > coupled into your circuits, then you do whatever you can to ruin that > coupling. > > -- > Dave's Engineering Page: http://www.dvanhorn.org > Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 > > -- > http://www.piclist.com hint: To leave the PICList > .....piclist-unsubscribe-requestKILLspam.....mitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu