I guess I've been a programmer too long. I ALWAY suspect software first, no matter how long it runs. I originally suspected I had a "window of vulnerability", where I would get an interrupt at the most inopportune time & didn't handle everything properly (because I didn't expect ANY interrupts). I verified I had disabled ALL interrupts, but suspected that MAYBE, somewhere in the code, I MAY have re-enabled them. Once you start digging into code, it's easy for me to put blinders on and become convinced it's a code problem. 'Nuff said. The new chip's working fine. Thanks for your input. Dennis ----- Original Message ----- From: "Tim Tapio" To: Sent: Saturday, November 16, 2002 9:36 AM Subject: Re: [PIC]:failed data location? > One question though, if the other systems are working fine, why would you > first suspect software? > > Component failure is a fact of life...no matter what the MTBF might be > (usually a very educated estimate), there will always be those that are DOA > or fail within a 24 - 48 hour time span...and some that wait 5 months. > Granted, failures are not common, but if something is working for months and > suddenly stops, my first inclination would not be software issues. > > But, that's just me. > > Tim > > > -----Original Message----- > From: pic microcontroller discussion list > [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Dennis J. Murray > Sent: Friday, November 15, 2002 9:17 AM > To: PICLIST@MITVMA.MIT.EDU > Subject: Re: [PIC]:failed data location? > > > I've been programming a LOOOONG time in many different languages, mostly > assembler. Believe me when I say I've made more programming mistakes and > snafus than most of you've EVER thought possible!!! As a point of > reference, my first FORTRAN program back in the 60's had well over 200 > errrors, yet the program had less than 100 lines of code!! Beat that! Over > the years, I've become very adept at tracking down programming errors - my > carrer depended on it! > > In this case, my first & only thought was "I screwed up in the program > somewhere", even though this particular unit had been running flawlessly > since May (no, I never considered the assembler - I've NEVER had an > assembler screw up my code!). > > I simulated the chip under MPLAB, isolating different sections & athrashing > them heartily - no failure. I figured it must be a timing-related program > failure, so I programmed a new chip and thrashed it every way I could think > of - no failure. > > Thanks for your input, Scott. I just don't feel comfortable that I'm out of > the woods by just replacing the chip. > > Dernnis > > ----- Original Message ----- > From: "Scott Touchton" > To: > Sent: Thursday, November 14, 2002 8:26 PM > Subject: Re: [PIC]:failed data location? > > > > I will throw my 2 cents into the ring on the issue: > > > > I have seen RAM in the 16C54 that toggles on its own accord. Even > > duplicated it with a combination of temp and supply voltage. The part was > > "in specified operating range" all the time. No code bugs, just good ol' > > marginal wafers. > > > > I was using in excess of 500K per year, and Microchip acknowledged the > issue > > with sincere apologies, but no remedy. > > > > > > I find it highly likely this is what you are experiencing. Though human > > error is usually the main culprit. > > > > -- > > 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 PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > email listserv@mitvma.mit.edu with SET PICList DIGEST in the body > > -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads