Mike Harrison wrote

>
> Just a thought - maybe there is an obscure setting somewhere, or library=
=20
> error in the device size
> that meant it was only programming part of the chip - this would explain=
=20
> it verifying OK.
> Reading a 'bad' chip on a known good programmer would probably make this=
=20
> obvious.
>

I'm hoping you're right, Mike  ...  I'm reading the manual and checking the=
=20
library files more carefully now, especially as the immediate pressure is=20
off.

There's something in what you've said that is triggering thoughts of=20
something I read about offsetting a file before loading the library or=20
burning or ...  ???

These eproms were supposed to be done and in the post yesterday to a place=
=20
interstate. They were then going to install them over the weekend and send=
=20
the next 10 over. So we kinda missed that daedline, but I still want to be=
=20
ready for the next lot.

What frustrated me the most was that I burnt the original library to eprom,=
=20
like the manual recommended  ...  before I installed a 'library' for serial=
=20
chips to do a batch .. which worked fine  ...  (downloaded from Dataman's=20
site)

Then when I went to re-install the original library from my saved eprom, it=
=20
just kept freezing the machine. Obviously my copy didn't work.


Just out of interest, this is directly from page 9 of the datasheet for ST'=
s=20
27C256B EPROM.

"Research shows that constant exposure to room level fluorescent lighting=20
could erase a typical M27C256B in about 3 years, while it would take=20
approximately 1
week to cause erasure when exposed to direct sunlight."

Regards,  Roger=20

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.