No...but, found the problem. Just goes to show what can get past you when = moving from legacy code to new stuff. The history was this used to be in a= n 16F877, so they spun the board for the 887, and "added features" which tr= anslates to added code, and more variables. The original author used the c= block directive, but hardcoded some variables at the bottom end of the RAM,= and as I added some additional variables it wrote over the top a couple of= these. For those wondering how I saw this, because the compile didnt show= this as an error, always review the listings, it shows up very clear there. So...isnt that how it goes? You post due to frustrations...and it shows its= elf right after. But as always.....thanks for listening. Client has new code this morning, = so hopefully he can now ship :-) --- On Mon, 6/16/08, John Temples wrote: > From: John Temples > Subject: Re: [PIC] 16F887 and corrupted RAM/EEPROM > To: "Microcontroller discussion list - Public." > Date: Monday, June 16, 2008, 11:58 PM > On Mon, 16 Jun 2008, alan smith wrote: > = > > Client has a 16F887 in a product,and they do limited > runs of 20 or so at a time.=A0 Maybe one out of the batch > shows problems that allude to that the ram locations are > being corrupted, and perhaps even EEPROM locations.=A0 The > value in the ram is loading a timer and so when its > bad....the timer is way off.=A0 It loads from EEPROM, and so > the code allows the user to check the value and its wrong. > = > Is the PIC protected from brownout? > = > -- > John W. Temples, III-- = > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist = -- = http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist