> because the compile didnt show this as an error,... Relocatabl mode and MPLINK had barfed about it... :-) :-) Best Regards, Jan-Erik. alan smith wrote: > 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 an 16F877, so they spun the board for the 887, and "added features" which translates to added code, and more variables. The original author used the cblock 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 itself 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. Maybe one out of the batch >> shows problems that allude to that the ram locations are >> being corrupted, and perhaps even EEPROM locations. The >> value in the ram is loading a timer and so when its >> bad....the timer is way off. 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