From PICLIST@MITVMA.MIT.EDU Fri Nov 15 13:09:10 2002 Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-7.13) id A2763DB00FE; Fri, 15 Nov 2002 13:09:10 -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 <0.007DD97A@cherry.ease.lsoft.com>; Fri, 15 Nov 2002 15:55:01 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 8749 for PICLIST@MITVMA.MIT.EDU; Fri, 15 Nov 2002 15:54:51 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 0340; Fri, 15 Nov 2002 15:54:10 -0500 Received: from *unknown [64.4.37.128] by mitvma.mit.edu (IBM VM SMTP Level 320) via TCP with ESMTP ; Fri, 15 Nov 2002 15:54:09 EST X-Warning: mitvma.mit.edu: Host *unknown claimed to be hotmail.com Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 15 Nov 2002 12:54:09 -0800 Received: from 207.88.130.242 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 15 Nov 2002 20:54:09 GMT X-Originating-IP: [207.88.130.242] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 15 Nov 2002 20:54:09.0620 (UTC) FILETIME=[2505C940:01C28CE9] Message-ID: Date: Fri, 15 Nov 2002 13:54:09 -0700 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: Micro Eng Subject: Re: [PIC]:failed data location? To: PICLIST@MITVMA.MIT.EDU X-RCPT-TO: Status: R X-UIDL: 277600734 X-Evolution-Source: pop://mailinglist%40farcite.net@mail.farcite.net/ X-Evolution: 000007a3-0000 ahhh...but Olin.... location 0x70 contains a variable called SysFlags. I use the 8 bits of this for system wide flags. Its been working just fine for the past several months. Then, all of a sudden, I put into a routine to check bit 8 of the register, where I set it in the ISR, and it has been setting for a while (read...working fine according to the watch window in ISD). So now my simple btfss isnt working. Strange...so I go back and watch it. Wait...the bit...isnt being set anymore. Strange, in that (ok...no flames....I didnt change the code yet its broke thing) I had simply added a subroutine that looked at that bit. So, being the simple thing to do, I change the location from 0x70 to 0x74 (next available location) and whoa...it WORKS! So now I set a new variable to point at 0x70 and simply to a movlw 0x55, and a movwf to 0x70, and what do I see...it never sets the bits. I suppose the silicon could have been punched thru, or the addressing isnt correct (yet all other registers work fine still). In other words, a functional register died. So yes, at times you accidently overwrite a bit, but those are easy to spot usually. If I take everything out of the code, simple lol looping routine, and it still fails....then I would tend to think its not code but hardware. Just bothers me to find a failure such as this, because I don't want to see the same thing occur in the field. I suppose I could put in reduncy by using a shadow register and doing a compare between them to determine if a register failed but who's to say the shadow might be a fail point? Ive actually seen a similar thing in CPLDs before. Simulation shows it should work, running a JTAG programmer to it and putting out the data to unused pins shows that IT DID BREAK. Being under tight schedule, and have used thousands of the part that never seemed to show the problem made me simple replace it. I don't really have a problem that this might be a one time in a million failure. My point of asking the question to begin with was...has anyone else seen the same thing? So far, it seems one other has. That might have been an enviromental issue. Mine is not. >From: Olin Lathrop >Reply-To: pic microcontroller discussion list >To: PICLIST@MITVMA.MIT.EDU >Subject: Re: [PIC]:failed data location? >Date: Thu, 14 Nov 2002 15:00:43 -0500 > > > I've had an occurrence recently of a system failure that "can't happen". > >World, please spare me another "the compiler has a bug since my perfect >program won't run" lament! > > > The only way I can figure that the circuit is behaving like this is if >the > > RAM location holding my flag is stuck. > >The ***ONLY*** way!!? You don't suppose for a second that you could have >done something wrong? > > > This would explain everything, but > > seems like I'm copping out. > >Yes, you are. > >You need a serious attitude adjustment if you ever want to be successful >at bug fixing. The only valid question is "what did **I** screw up?" >Only then will your mind open to possibilities that you aren't seeing now. >Sometimes in the process of tracking down your screwup and verifying the >operation of what you designed, you run accross irrefutable evidence that >something else beyond your control is actually busted. This is rather >rare, and you're nowhere near that yet. > > >***************************************************************** >Embed Inc, embedded system specialists in Littleton Massachusetts >(978) 742-9014, http://www.embedinc.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 _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.