can an UV-PROM die?

[0db]

hi, there is a dude telling me that he has just thrown a UV-PROM into the recycle bin because he is unable to read it. The PROM has been installed on an electronic board for years and perfectly working when recently checked.

Then the board moved from a laboratory to his house, and now he says "I trashed it because died", but one thing is if the content gets somehow corrupted (UV exposure? during a sunny day? because it kept the board on the desk near to a window?), one thing is the electronic inside the PROM can suddenly and unjustifiably die.

Personally, I do find hard to believe the second one.

What do you think?

[greenpossum]

Of course they can die. It's a semiconductor device and so subject to those failures. Plus the trapped electrons can leak out with time. I have tossed out quite a few UV EPROMs that I could not fully erase, or after erasure, I could not program.

[Gyro]

There are typically three forms of death.

The first is charge leakage (which also eventually affects Flash), where the 'programmed' charge one the floating mosfet gates leaks away over the years. This causes 0 bits to slowly (going through intermittent) transition to 1s. As long as you have an image of the flash code, it is normally possible to re-write the same UVeprom and achieve pretty much the original life again.

The second type is 'Sunburn' This used to be a common problem in labs where people set the UV lamp timer too long - particularly in labs with shared erasers where thoughtless people would put their eproms in and reset the timer without taking other peoples' out. This results in bits stuck at 1, and impossible to program to 0 again.

The third type is bits stuck at 0 after erasing particularly after several cycles of use. Sometimes curable by extending the erase time on well-used eproms for a few more cycles,  until you eventually lose them to the effects of 'sunburn.

Obviously types two and three are destined for the bin. Type one is reversible (as long as you've remembered to capture an image in good time).


P.S. It's important that the window is covered, preferably with a UV blocking Aluminium label for maximum life (I'm talking decades).

P.P.S In terms of your specific question. Leaving an eprom in a sunny window, especially in a sunny place like Zambia, might cause erasure over a week or two, however if the sun is shining through glass, then that would block the needed UV-C wavelength. I suppose it is possible that operation in strong light could cause excessive on-die leakage currents, but probably not to the extent of self-destruct. A few people actually had some success using UV-eproms as primitive imaging chips in the past. If the eprom had any sort of label on the window, this is pretty unlikely.

[TomS_]

(UV exposure? during a sunny day? because it kept the board on the desk near to a window?)

It is my understanding that sunlight doesnt contain (enough of?) the required wavelength to erase a UV EPROM - at least not within any "reasonable" period of time. I dont think one sunny day would do it.

But I suppose its not necessarily a guarantee that some sunlight couldnt affect one. Although.. I personally have EPROMs that, as a kid some 20+ years ago), I left on the window sil for some time (maybe a couple of weeks) thinking they would be erased, but I can still read legible contents from these days (text strings etc). Whether there is any corruption to binary contents I wouldnt know unless I attempted to disassemble them.

[MadTux]

Very interesting.
Never heard of the "Sunburn" failure mode before. What is the failure mode behind that?

The only "it''s dead Jim" failure mode I was aware until now, is hot carrier injection, if the EPROM is writen/erased a lot of times and electrons tunnel into the gate oxide. But then the bit will probably be stuck in programmed/0 state, instead of erased/1, as in "sunburn" failure mode. Probably the #3 failure mode, you described?

[james_s]

I've had UV and mask ROMs fail for no obvious reason. A couple years ago I fixed two different arcade games my friend owns that turned out to have bad ROMs. I've encountered corrupt data a few times, in one case I could read it fine on my reader but it failed in the actual device. I've also had some fail such that they were completely dead and couldn't be read at all. Hard to say what happened internally, it could have been as simple as an open connection on chip enable or output enable.

I've never had sunlight erase an eprom, but even ambient room light will cause read errors now and then. I worked on another arcade game once that would crash when I looked inside it with a flashlight, turned out the sticker had fallen off one of the program ROMs and when illuminated the program would crash.

[T3sl4co1l]

Believable; the mechanism is probably something like, free charge carriers affecting the sense amps or such.

It's not direct leakage, as EPROMs store charge on an insulated metal (or silicon) gate.  UV-C is required to loosen charge carriers in that situation (via the photoelectric effect, give or take the detail that it's emission into/through SiO2, rather than vacuum).  The data is fine, and removing the light source returns normal operation.

DRAM however stores the charge under silicon channels, allowing this:
https://hackaday.com/2014/04/05/taking-pictures-with-a-dram-chip/

Tim

[Gyro]

Very interesting.
Never heard of the "Sunburn" failure mode before. What is the failure mode behind that?

The only "it''s dead Jim" failure mode I was aware until now, is hot carrier injection, if the EPROM is writen/erased a lot of times and electrons tunnel into the gate oxide. But then the bit will probably be stuck in programmed/0 state, instead of erased/1, as in "sunburn" failure mode. Probably the #3 failure mode, you described?

I don't really know. I always assumed that it induced permanent leakage in the gate oxide so that they wouldn't hold charge, but looking back, it seems unlikely now. Maybe it was something like changing the thresholds of the sense amplifiers.*

What I do know is that it was the cause of many a heated argument in the lab, particularly when some of the devices were UV erasable micros and all were in relatively short supply, so could easily lose you a day. Hence the use of relatively expensive Augat prom carriers (basically gold plated turned pin sockets) to avoid broken pins.

... Yes, that sounds like the third failure mode.


* Although it would only show up as a few corrupted locations on the program verify.

[Zero999]

(UV exposure? during a sunny day? because it kept the board on the desk near to a window?)

It is my understanding that sunlight doesnt contain (enough of?) the required wavelength to erase a UV EPROM - at least not within any "reasonable" period of time. I dont think one sunny day would do it.

P.P.S In terms of your specific question. Leaving an eprom in a sunny window, especially in a sunny place like Zambia, might cause erasure over a week or two, however if the sun is shining through glass, then that would block the needed UV-C wavelength. I suppose it is possible that operation in strong light could cause excessive on-die leakage currents, but probably not to the extent of self-destruct. A few people actually had some success using UV-eproms as primitive imaging chips in the past. If the eprom had any sort of label on the window, this is pretty unlikely.

No UVC gets through the ozone layer. Some UVB does, which is probably responsible for erasing the EPROM.
https://en.wikipedia.org/wiki/Ultraviolet#UVC

[David Hess]

Besides defective parts, the only UVEPROM failures I have experience were trapped charge preventing erasure with common parts being useful until about 50 erase and program cycles but I suspect there was considerable variation.  I have never noticed any effect from over-erasing.

Mask ROMs from some manufacturers, MOSTEK comes to mind, are known to be unreliable.  I am not sure of the exact cause but suspect poor non-hermetic packaging which allowed external contamination along the lead surfaces; this was also a problem with plastic packaged logic chips from time to time.