>-----Original Message-----
>From: Robert Rolf [mailto:Robert.Rolf@UALBERTA.CA]
>Sent: 15 December 2003 16:26
>To: PICLIST@MITVMA.MIT.EDU
>Subject: Re: [PIC:] EEPROM read failure
>
>
>Are you programming the EEPROM at 3.3 V or 5V? Have you tried
>using a lower clock rate (4mhz) just to see if it's a timing
>(setup) problem?
>

Initial calibration data is programmed by the production programmer at
3.3volts nominal (checked at 3.1 and 3.5 but only at 25C).  However, during
setup/test the internal calibrations can be changed via an I2C link, in
which case the PIC performs it's own writes at 3.3 nominal.

>While I have no experience with your particular part, I did
>find that 16LF876's needed to be programmed at 5V to ensure
>reliable reads at 2.5V and high (50C) temperature. Probably
>has something to do with the amount of charge being buried
>under the floating gates and threshold shifts in the sense
>amps (or charge pump inadequacies at 3.3V). Since it wasn't a
>big deal for my project, I didn't pursue the 'out of spec' issue.
>
>Are the failing parts all from the same production lot number?
>

It appears that all the parts that failed are from the same date code.  The
devices are programmed using ICSP, and the PIC shares it's Vdd rail with
devices that are definitely not 5v tolerant, so increasing programming
voltage would be a PITA.  However, it sounds like it would be worthwhile
trying to re-program the fails parts at 5 volts to see if this is the cause
of the problem.


>I have also been burned by early 68HC11E2 parts that could not
>run code reliably at full speed spec. Fortunately I was able
>to drop the clock rate to work around the problem, and in the
>end saved on the power budget because of the reduced clock
>rate. Motorola knew about the problem (factory engineer had
>the answer immediately) but I never saw an errata for this
>fault. That, and allocations was one reason I moved to PICs.
>
>Presumably you are CRCing your calibration data to catch this
>problem before it impacts your readings. Do you CRC your
>executable code to catch a possible similar problem with the code?
>

Cal data has a checksum, program memory at the moment does not.  However,
following this experience I will implement this ASAP.

Thanks for sharing your experiences, hopefully I can resolve this as quickly
as possible.  Fortunately all product is extensively tested over it's full
rated temperature and voltage range which has enabled us to catch the few
parts that have failed.

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
postmaster@bookham.com.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body