UV EPROM “Over-programming"

[@rt]

Hi Guys
While I’m not exactly new to the hobby, I sometimes think “beginner questions” are best asked in here.

There are several references to Over-Programming in the old UV erasable EPROM datasheets,
and other references can be Googled without really explaining what EPROM over-programming really means.

I realise the fast programming algorithms (Presto, Rapid) deliver a shorter pulse and then verify, then pulse again if necessary,
as this reduces the programming time overall, but is there any other negative effect of over-programming?
Cheers

[MK14]

http://eeshop.unl.edu/pdf/27128.pdf

My interpretation is that the over-programming is a VITAL part of the fast programming algorithm. That must be done to ensure reliable programming of the EPROM.

If you fail to do the over-programming, it may be unreliably programmed.

[capt bullshot]

Yes, thats the point.
The repeat until "0" is read pulses bring the necessary charge to the isolated gate. The amount of charge is just enough to cause the memory cell to read the "0". For reliability sake, you need some excess charge on the floating gate, thats what the "overprogramming" does.

[bktemp]

From this application note:
http://www.atmel.com/Images/DOC0578.PDF

memory locations that have been previously programmed can be partially
erased by programming subsequent locations (due to the
elevated voltage on the same row or column in the memory
array)

So applying excessive programming pulses may degrade already programmed memory locations. That's why most algorithms program just enough and add a bit more but not too much to avoid changing other memory locations.

[MK14]

From this application note:
http://www.atmel.com/Images/DOC0578.PDF

memory locations that have been previously programmed can be partially
erased by programming subsequent locations (due to the
elevated voltage on the same row or column in the memory
array)

So applying excessive programming pulses may degrade already programmed memory locations. That's why most algorithms program just enough and add a bit more but not too much to avoid changing other memory locations.

My understanding is that it is the other way round.

If you missed the over-programming, so that it was only just at the logic level '0'. Then programming more locations could make it incorrectly read '1', i.e. be slightly erased.

So MORE, not less programming is required. As implemented by the over-programming part of the algorithm.

tl;dr
It is the "Marginally programmed" bits that they are worried about. Over-programming (and extra verification, extended voltage tests) are trying to reduce or eliminate marginally programmed bits which can be unreliable and not last the 10+ years life time.

[MK14]

CORRECTION:

On reading much more of the application note, it seems that there is a (rare/complicated) mechanism, which means that if you programmed it significantly too much (probably outside of the recommended programming algorithms ratings), it can self erase to an extent (rarely).
If you want more details, please read the application note (especially the final few pages).

But to be clear, the recommended over-programming still needs to be done.

[AndyC_772]

A fast, reliable programming algorithm for an EPROM looks something like this:

- erase device
- program 1st location with a short write time
- make a note of how much write time has been used in total so far
- read data back
- if it doesn't match, program it again. Keep doing this until it does read back correctly
- program the same location again, with the same value, using a write time equal to the sum of all the write times that have already been applied to that location. (Or half of it, or twice as much, or whatever the device manufacturer recommends).
- go on to the next location.

When you program a location, what you're doing is injecting charge by force (hence the 25V or 12.5V VPP) into an insulated gate. The amount of charge required to turn on the FET underneath it is variable, and depends on how that individual chip (or even, that individual cell) was fabricated.

The longer you maintain a write pulse, in total, the more charge is loaded onto the gate.

There will be some amount of charge which is guaranteed to cause a bit to flip reliably, but it's not a good idea to do this. For one thing, your programming algorithm will be very slow, but you also end up with excessive charge on the device - and I can see how that might allow bits to be influenced (ie. switched) by surrounding bits.

By building up charge a little at a time, you're:

a) determining, on a byte-by-byte basis, how much charge is actually needed to program that byte

b) ensuring that each byte has significantly more charge than the absolute minimum that will cause it to switch. This ensures safety margin to cope with changes over time and temperature.

c) ensuring you don't over-charge any cell, to the point where it might influence adjacent cells, or be hard to erase

d) speeding up the programming of the device considerably

Meanwhile, in other news, UV erasable devices are obsolete. Self-programming Flash is a much better option in every way. (Algorithms like this one are built in!)

[SoundTech-LG]

"Self-programming Flash is a much better option in every way. (Algorithms like this one are built in!)"

Maybe so...  but I am having nothing but problems with AMD Am29F016D in a Dataman 40PRO programmer (Elnec SmartProg2).

Cannot read ID. Disable that, will read all addresses. Cannot Erase, Blank Check, Program. Buffer Data on a blank (new) chip looks funny. Dataman support wanted selftest details, no dummy selftester, so I used all 560 resistors. Passed self test. Now they want a serial number off the adapter. It's pin for pin, so why??? Or can I not use a pin for pin setup.

[@rt]

Thanks for the explanation! I'm sure I can handle it.
The data sheet for the device M27C800 does show
suggested timings, but I wasn't clear on the meaning of that term.

I'd never use one in a new project, but this is for a vintage computer.
Also I find them somewhat fascinating,
but not enough to give up all of those ports for a lousy 1Mb

[David Hess]

A fast, reliable programming algorithm for an EPROM looks something like this:

- erase device
- program 1st location with a short write time
- make a note of how much write time has been used in total so far
- read data back
- if it doesn't match, program it again. Keep doing this until it does read back correctly
- program the same location again, with the same value, using a write time equal to the sum of all the write times that have already been applied to that location. (Or half of it, or twice as much, or whatever the device manufacturer recommends).
- go on to the next location.

And for a production programmer, do all the above at the worst case supply voltage.

[BrianHG]

And for a production programmer, do all the above at the worst case supply voltage.

I though this was only during the verifies, to read with vcc min, & vcc max, and if error occurs, burn the location again with a stronger VPP.
Perhaps the rules slightly differ from manufacturer to manufacturer...

[David Hess]

And for a production programmer, do all the above at the worst case supply voltage.

I though this was only during the verifies, to read with vcc min, & vcc max, and if error occurs, burn the location again with a stronger VPP.
Perhaps the rules slightly differ from manufacturer to manufacturer...

I have seen programmers which did this for more than just verify.  The over-programming is going to be different with different supply voltages but maybe they take that into account.  Verify will only catch a gross malfunctions.

[@rt]

Ok, I've successfully done Reading, blank check, write, and verify. The first write and verify last night,
but with fixed timings, so it took two passes to verify. I think I’ll do ST’s Presto algorithm since they seem
to be the most commonly available devices out there now.

Next question.
At the moment all control lines for the EPROM are software controlled except for Vpp (programming voltage).
I have a manual switch where the board pauses for a while in programming mode and indicates with an LED,
for the user to switch from Vcc to Vpp, where it remains until the write operation is complete.

I’d like to do this in software as well, but there’s a risk of the wrong signals being present at power up
which might cause a location of an EPROM already in the socket to be programmed.
So any ideas of a circuit that can guarantee a signal pin will power up no more than 5 Volts until the micro is stable?

[BrianHG]

A simple 2 input and gate like a 74HCxx series.  The output should drive your HV supply, 1 input will go to the MCU and the other will use a 1uf to GND, with a diode to vcc to discharge the cap during loss of power, and, a 1 to 10 meg pull-up.  This should give you MCU time to power-up blocking your HV enable.

[@rt]

Thanks, that makes so much sense it seems like a silly question now.
I’ve used the same thing to hold chips in reset for power up, then just the and gate is additional.
Thanks

[MK14]

A simple 2 input and gate like a 74HCxx series.  The output should drive your HV supply, 1 input will go to the MCU and the other will use a 1uf to GND, with a diode to vcc to discharge the cap during loss of power, and, a 1 to 10 meg pull-up.  This should give you MCU time to power-up blocking your HV enable.

That was almost exactly what I was going to suggest.

But there is also a rarer problem. Which is during the power off/down sequence, location(s) could be corrupted. It is quite possible it is ok, it depends. I.e. as the 5V power rail collapses (assuming the program voltage is always on), the MCU will/may "crash" vary briefly as the 5V rail disappears, during which it may try and write to the EPROM, and succeed, if the Vpp is still present.
This is part of the reason why some MCUs have brownout protection, which is another possible solution.

To play even safer, you can discharge the capacitor, in your software immediately after programming. I.e., disable the Vpp, with the time delay to charge the 1uF cap, being much longer than the very short duration power off crash (brown out).

tl;dr
In the old days of Eproms and CMOS battery backed up ram. This was a common problem/issue.

It can be amazingly difficult to make it 100% reliable. Especially during power on and power off situations.

[@rt]

I wasn’t “so” concerned about power down because when the Vpp is software controlled it should be long gone by then.
The AND gate should prevent that. I can turn off the control input that turns on Vpp after programming.

There will always be a verify after program, which I’ll leave be, even after the interleaved write/verify is implemented.

[MK14]

The AND gate should prevent that. I can turn off the control input that turns on Vpp after programming.

The MCU may try and turn the AND gate back on again, when you power it off. So if Vpp is still present, it could corrupt the EPROM.

E.g. the 5V rail has had the power turned off, and has dropped down to 4.0000V, and will be 3.950V .. 3.900V etc, every millisecond, depending on the capacitance on the rails etc. It might only take 100uSec of such a brownout, to corrupt the EPROM.

At perhaps 4V the MCU will go funny (crash), and may try and do random things such as turn the port pin on for the AND gate, and try and write/corrupt the EPROM.

I agree this is probably a rarer (or much, much rarer), problem, than the power on one.  Feel free to not worry about it.

tl;dr
It only takes about 10 nano seconds for the AND gate to switch, once the capacitor is charged up (if I understand the circuit correctly).

Solution:
Either don't worry about this (since it is battery backed up CMOS ram, where this becomes especially problematic, as it can take only tens of nano seconds to corrupt) or
enable brown out on the cpu and/or charge the AND gates capacitor via a port pin, so when the MCU disables it (it discharges the capacitor, ideally via a diode to make it discharge very quickly, but charge up slowly via the resistor), it will take a while to re-enable it, which will easily cover the power down time (brown out).

[@rt]

I think I understand, but I also realised the EPROM is dead at power down before the micro.
The micro is 3.3V, and talks with level shifters to the EPROM. It’s probably just a larger capacitor/s on it’s power rail.
I could extend that to be sure 12V & 5V is truly gone first pretty easily.

I’m only thinking of other ideas to save microcontroller pins.
There is no soft power and none of it knows when it will be turned off.

[MK14]

I think I understand, but I also realised the EPROM is dead at power down before the micro.
The micro is 3.3V, and talks with level shifters to the EPROM. It’s probably just a larger capacitor/s on it’s power rail.
I could extend that to be sure 12V & 5V is truly gone first pretty easily.

I’m only thinking of other ideas to save microcontroller pins.
There is no soft power and none of it knows when it will be turned off.

I somehow thought it was 5V. The MCU being at 3.3V (and with you possibly/optionally extending its hold time with caps), should help a lot and if the EPROM loses power first, that is even better!

As with many threads, because I can't actually see the full schematic and/or see or mess with the hardware. It makes it that much harder to realize/spot things like that. Or it's my fault because the details are in the thread, but there is too much reading to do.

I hate it when ram or flash or EPROMS get corrupted.

Anyway, good luck with your project.

[@rt]

Yes, there’s no telling from info provided so far, what the microcontrollers are.

Anyways, does this look right (forgiving the crude drawing) ?
The state of MCU IO should switch between 5V & 12.5V at the output Vcc/Vpp.
Additionally, even if powered up with MCU IO high, the delay should prevent Vpp output until the cap is charged.
I have not included bleeding it off.

[MK14]

EDIT: It seems ok, I got mixed up.
Assuming the AND gate is open collector.
(The striked out bit, I mistakenly was thinking of a NAND gate, sorry!)
I was incorrectly thinking open collector transistor = on = 0V = logic one (but it is the other way round  )

Assuming the AND gate is open collector (so it can reach 12.5V), then the logic for that bit seems to be the wrong way round.
Many solutions, including using a NAND gate or switching the resistor/cap around the other way.
EDIT: Logic not as easy as using NAND, as really one of the inputs (the top one) would need inverting.

EDIT3:
You might want to consider connecting the diode to 5V rather than the inverter. Then there will be less voltage drop, no current limit and no risk of power rail glitches, during inverter switching. (Unless you want to turn the 5V rail off as well, sometimes).

[@rt]

Hi I went for this. It’s similar to the first, and appears to be working nicely.
The top buffer is a quarter of a TI SN754410 Quad Half H-Bridge driver,
which could just as easily be called a quad non inverting buffer.
The chip is supplied with 5 Volts for it’s internal control logic, and an arbitrary voltage for output power (Vpp).

The beauty of it is that it’s outputs are high impedance when the enable pin is low.
I checked the M27C800 EEPROM data sheet, and the forward voltage drop for the 5 Volt state is no problem
It’s logic high is 2.8V IIRC. The chip is probably overkill, but the project is a one off, and I have plenty of these.

The SN754410 is advertised glitch free for power on/off, and that feature is tried and tested,
as I used them for a core memory project to drive the addressing matrix where glitches would corrupt memory.

[@rt]

I never followed up, but the two ideas I had were both a success
The first was to incorporate a different IDE driver into an Amiga ROM.

The second was to incorporate an audio CD player with
spectrum analyser into an Amiga CD32 ROM.
The spectrum analyser CD player was written after the
mask ROMs were produced for the CD32, so the stock
CD player is missing that functionality.

It's cool that I might be the first "civilian" to see it

https://youtu.be/t3eccKFcBNE