Hi out there, I have not posed a question to this respected forum for a while.
I hope someone out there has an answer for me.
I am doing low power development and have been using the 16C65/JW (Eprom
version)
configured in LP mode and running it at 3V and 200KHz, basically at the edges of
the
mode. I have now gone through 10 chips all with the same problem. They start off
working fine and then after about 2 weeks they will not work at 3V and I can
only use
them from 5V and XT setting. The chips (I am told by the local supplier) have a
life
of 20-30 erases and I never reached that limit. They seem to be dying on me
faster
than they should. In fact if they died it would be one thing but they work at a
higher voltage.
Has anyone developed under these conditions i.e. 3V 200KHz or heard of similar
problems.
>I am doing low power development and have been using the 16C65/JW (Eprom
>version configured in LP mode and running it at 3V and 200KHz, basically at
the >edges of the mode. I have now gone through 10 chips all with the same
problem. >They start off working fine and then after about 2 weeks they will
not work at >3V and I can only use them from 5V and XT setting. The chips (I
am told by the >local supplier) have a life of 20-30 erases and I never
reached that limit.
>
>Moshe
This sounds like a problem with your programmer.
What programmer are you using? Is it verifying the programmed chip
at the correct operational voltages? (please tell me you are not
programming the chip at 5V?)
>At 03:25 PM 21/08/96 +0300, you wrote:
>
>>I am doing low power development and have been using the 16C65/JW (Eprom
>>version configured in LP mode and running it at 3V and 200KHz, basically at
>the >edges of the mode. I have now gone through 10 chips all with the same
>problem. >They start off working fine and then after about 2 weeks they will
>not work at >3V and I can only use them from 5V and XT setting. The chips (I
>am told by the >local supplier) have a life of 20-30 erases and I never
>reached that limit.
>>
>>Moshe
>
> This sounds like a problem with your programmer.
>
> What programmer are you using? Is it verifying the programmed chip
> at the correct operational voltages? (please tell me you are not
> programming the chip at 5V?)
>
>___Bob
>
The problem here is not that the programmer is failing to program correctly.
If that were the case then his "programmed" 0's would slowly migrate and
become 1's This migration would appear first at 5V and not at 3V. The fact
that the chips continue to work at 5V means his "programming margins," and
therefore programmer, are ok.
The problem is that the devices are not being FULLY ERASED before
programming. A 5V only programmer will not pick that up as the VDD min is
required to check the "erase margin." This is the only real _practical_
failure of a 5V only programmer. They suck if you are using the windowed
chips at a lower voltages.
Solutions: (to be followed religiously!)
Erase the devices for a whole hour before programming. DON'T EVER rely on
your 5V only programmer to check erase margins if using the parts at lower
voltages.
Cover the window at all times other than when erasing. This will prevent
slow erasure caused by the ambient light.
Consider using 16LC65s as they are rated to work at 3V. The standard parts
are rated to only a 4V minimum and this may also cause problems.
At 08:08 AM 8/23/96 -0500, you wrote:
>... They start off working fine and then after about 2 weeks they will
>>not work at >3V
This reminds me of a situation I experienced many years ago, with the
venerable 2708 EPROM. We had cases in which they would check out on our
Data I/O programmer, but would work unreliably in-circuit.
Turned out to have two causes (which Jim Robertson's email reminded me of):
both caused by our misguided but well-meaning technician. First, he noted
that the EPROMs would verfify as "erased" on the programer after far less
time under the UV than we normally specified. Second, he noted that the
EPROMS would verify as "programmed" after only a few seconds in the
programmer. So, he "saved time" by erasing the devices for only a few
minutes, and then interrupting the programming cycle very early on.
Of course, neither case was valid: the devices were neother adequately
erased,nor were they fully porgrammed, causing unold problems until we
determined the cause! It was a case of misplaced ingenuity.
