From PICLIST@MITVMA.MIT.EDU Fri Nov 15 06:33:55 2002 Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-7.13) id A5D318D90072; Fri, 15 Nov 2002 06:33:55 -0800 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.007DB93A@cherry.ease.lsoft.com>; Fri, 15 Nov 2002 9:19:48 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 2841 for PICLIST@MITVMA.MIT.EDU; Fri, 15 Nov 2002 09:19:40 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 0307; Fri, 15 Nov 2002 09:17:40 -0500 Received: from *unknown [68.13.69.197] by mitvma.mit.edu (IBM VM SMTP Level 320) via TCP with ESMTP ; Fri, 15 Nov 2002 09:17:40 EST X-Warning: mitvma.mit.edu: Host *unknown claimed to be madmax.botkin.org Received: from localhost (dale@localhost) by madmax.botkin.org (8.11.0/8.9.3) with ESMTP id gAFEHfo12745 for ; Fri, 15 Nov 2002 08:17:41 -0600 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 15 Nov 2002 08:17:41 -0600 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: Dale Botkin Subject: Re: [PIC]:failed data location? To: PICLIST@MITVMA.MIT.EDU In-Reply-To: X-RCPT-TO: Status: R X-UIDL: 277600665 X-Evolution-Source: pop://mailinglist%40farcite.net@mail.farcite.net/ X-Evolution: 0000076d-0000 On Fri, 15 Nov 2002, Michael Rigby-Jones wrote: > > OK, so it's a hardware failure. It happens, so you toss the chip and move > > on with your life. So why are we now turning this into a pissing match in > > front of 1800 people on the PICList?? Both of you need to take it off > > list or just drop it. > > > While I agree about slagging matches on the list, "toss the chip and move on > with your life" isn't what any responsible engineer would do. If this > happened to me I'd want to know exactly what went wrong, and what the > chances are of this happening to other products I have in the field and what > MChip are going to do about improved testing. Software bugs are one thing, > but if you can't rely on the hardware to work properly for the expected life > of your product them you have a big problem. Oh ferheavenssake. ONE $3 chip fails. You KNOW it failed (worked fine for weeks, failed, replacement works fine). The replacement works perfectly, as do other identical units in the field. Call it infant mortality, since it's obviously on the leading edge of the bathtub curve. How many thousands are you willing to spend on failure analysis to find out that the chip did indeed fail because either A.) it was flippin' defective, or B.) you broke it by operating it outside of its safe operating area? If you're using the chip within the power, temperature, humidity, vibration and other limits specified in the data sheet, you can reasonably expect the performance specified by Microchip or whatever manufacturer. If you're outside any or all of these limits, all bets are off. QA and testing data are available on their web site. Using THIS information to determine what the chances are of the same thing happening to other units in the field is what "any responsible engineer" should be doing. Component failures are a fact of life that we have to deal with, no matter what we build. Even a good manufacturing lot will have some number of premature failures. If you get a whole bunch of failures and you know it's NOT your fault, then it's time to call the manufacturer and investigate. But excepting very special applications (life support, spacecraft, weapons systems) a single failure is pretty much a non-event. Dale -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.