From PICLIST@MITVMA.MIT.EDU Thu Nov 14 10:38:25 2002 Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-7.13) id ADA1115800C6; Thu, 14 Nov 2002 10:38:25 -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 <15.007D8618@cherry.ease.lsoft.com>; Thu, 14 Nov 2002 13:24:32 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 8952 for PICLIST@MITVMA.MIT.EDU; Thu, 14 Nov 2002 13:24:24 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 6096; Thu, 14 Nov 2002 13:23:02 -0500 Received: from pop017.verizon.net [206.46.170.210] by mitvma.mit.edu (IBM VM SMTP Level 320) via TCP with SMTP ; Thu, 14 Nov 2002 13:23:01 EST X-Comment: mitvma.mit.edu: Mail was sent by pop017.verizon.net Received: from djm ([151.199.99.135]) by pop017.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021114182300.XUXE1423.pop017.verizon.net@djm> for ; Thu, 14 Nov 2002 12:23:00 -0600 References: <00e001c28bfc$d5792120$0a01a8c0@djm> <54p7tuktv03l6ii7afh19c4dltj2p3vjnd@4ax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at pop017.verizon.net from [151.199.99.135] at Thu, 14 Nov 2002 12:23:00 -0600 Message-ID: <000601c28c0a$d8b07600$0a01a8c0@djm> Date: Thu, 14 Nov 2002 13:22:50 -0500 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: "Dennis J. Murray" Subject: Re: [PIC]:failed data location? To: PICLIST@MITVMA.MIT.EDU X-RCPT-TO: Status: R X-UIDL: 277600479 X-Evolution-Source: pop://mailinglist%40farcite.net@mail.farcite.net/ X-Evolution: 000006c4-0000 Uninitialized variables is a real newbie problem - trust me, that ain't it!! Everything's running in the same bank, so that's not it. No interrupt routines (interrupts disabled)- everything's polled, so that's not it. Reread what I wrote - this same chip's been working properly for about 5 months - day in and day out. When it failed, it failed consistently - not random failures! Hard reset didn't fix it either. New chip's working fine, but my question is - how long?? ----- Original Message ----- From: "Mike Harrison" To: Sent: Thursday, November 14, 2002 1:04 PM Subject: Re: [PIC]:failed data location? I'd be highly surprised if it was a hardware problem - it's probably doing something you're not looking for - bank-select bit problems, watchdog timing out, accidental vairable overlaps, or unintentionally overwriting the byte the flag is held in - just because your search only shows it being set in one place doesn't mean there aren't other ways it could get changed. Of course in this instance you could try changing the chip - if this fixes it it may still be an uninitialised variable issue On Thu, 14 Nov 2002 11:42:29 -0500, you wrote: >This "Failed Location" problem has me wondering -- has this problem ever >been experienced for other chips (i.e. '509A series)?? I KNOW it's an old >style chip & I should have moved to it's replacement, but I have a lot of >the '509's around. Ya use what ya got!! > >I've had an occurrence recently of a system failure that "can't happen". >The circuit uses a photodetector to measure sunlight, then activates >external circuitry ONCE for dawn, then once again at dusk. This cycle >repeats every day. I use a RAM flag that toggles when the chip activates >the external circuit. The flag must be 1 in order to trigger the circuit at >dusk and 0 in order to trigger the circuit at dawn. The circuit is now >consistently only triggering at dusk, which technically cannot occur! > >I performed a search on the assembly code for the flag and it IS only set in >the external circuit activation routine - which means the flag will toggle >(from 0 to 0ffx) on each call (one at dawn and one at dusk). The program >will not allow 2 dusk activations back-to-back -- you MUST have a dawn >activation in between in order to activate the logic to check for dusk! I >read the program back from the chip and compared it to the original and they >match. > >The circuit is running off a 12V motorcycle battery with a drop-down >regulator supplying 5 volts. I checked - the voltage is still 12.8 volts on >the battery & the regulator's still doing it's thing. This particular >circuit has been running flawlessly since May and just failed 2 weeks ago. > >The only way I can figure that the circuit is behaving like this is if the >RAM location holding my flag is stuck. This would explain everything, but >seems like I'm copping out. Has anyone else experienced anything similar?? > >BTW, I'm not a real newbie at programming. I've been doing assembler >language professionally since the mid-60's (but I'm not senile yet, either - >I don't think!). > >Thanks! >Dennis -- 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