My EPROMs need light to work properly! - Page 1
Forum section: electronics / beginners

author: titmouse001
author_rank: Newbie
timestamp: May 17, 2025, 06:01:32 pm
content: Why do my EPROMs need light to work properly!Yes, you read that right - they need light.I've been using ST M27C256B EPROMs for a while in a home project. Everything seemed fine until I noticed something strange - when I turn off the light things start acting up. The EPROMs start passing corrupted instructions to my Z80, and the whole thing just stops working.But when I turn the lights back on, it works again!I've tested multiple EPROMs of different speeds and sizes, but all of them are affected by light. I only figured this out after I started putting stickers over parts of the chip to track versions. I was pulling my hair out, checking my Arduino code, Z80 assembly, and hardware for some kind of bug... and it turns out the sticker was just blocking the ambient room light!Has anyone else experienced this bizarre behaviour with EPROMs? Are they getting to an age where the internal chemistry somehow relies on external light to function?

author: xvr
author_rank: Frequent Contributor
timestamp: May 17, 2025, 06:14:00 pm
content: Check connection of all pins of EEPROM. I seen the same effect (not with EEPROM, but with another IC near it) many years ago. Light will raise power consumption level of chip that lead to increasing noise level on power rail. Chip in question had broken wire from its output to address latch IC, and when it was exposed to light it generates enough spikes on voltage rail to force latch IC latch valid data

author: Benta
author_rank: Super Contributor
timestamp: May 17, 2025, 06:52:14 pm
content: You probably programmed them without a sticker over the window, which throws the read/write amplifiers off kilter.Sloppy and not what the datasheet says. Window should only be free when erasing.

author: SteveThackery
author_rank: Super Contributor
timestamp: May 17, 2025, 09:27:29 pm
content: Quote from: titmouse001 on May 17, 2025, 06:01:32 pmYou do realise that there should be a completely opaque (typically metal foil) sticker over the window, don't you? You should never program or use an EPROM without the sticker on.

author: CaptDon
author_rank: Super Contributor
timestamp: May 17, 2025, 09:37:07 pm
content: We programmed tens of thousands of Eproms without the stickers in place during programming and with lots of ambient light shining on them and never had a problem like you describe. What exactly is your 'Z80' system and what programmer are you using? I really hate the algorithms in some of the programmers that do the 'quick programming' routine. How long have these devices been programmed? When we are developing code we program without the stickers, run code evaluations without the stickers and if we decide it is a beta 'keeper' version we put the stickers on and mark the version and rev number on the sticker. No Eprom has ever failed to work correctly even after years of storage when we need to retrieve a rev level stored on an Eprom. Your experience is not typical by any means.

author: titmouse001
author_rank: Newbie
timestamp: May 17, 2025, 09:46:36 pm
content: Cheers all!I've been burning all my EPROMS without stickers.I'll cover them up now after erasing - never really bothered here in the UK.Tried leaving one in the sun once, and it took 3-4 weeks to even begin erasing!I'll let everyone know how it goes

author: CaptDon
author_rank: Super Contributor
timestamp: May 17, 2025, 10:04:46 pm
content: I think Intel made an app note comment back in the 1702/2708/2716 days that one week in the sun 'could' begin to erase data. One thing we did find was not to program an Eprom taken directly from a UV eraser where the lamp had just gone out or where the Eprom was removed while the lamp was still lit. We found that under that condition they would often fail the verify command at the end of the program cycle. We tended to place them on conductive foam and allow them to 'rest' for about 30 minutes. You won't find that in any app note!!

author: David Hess
author_rank: Super Contributor
timestamp: May 17, 2025, 10:48:33 pm
content: I suspect you are either not erasing the EPROMs fully or not programming the EPROMs fully. The erase time goes up as the EPROM wears out.Better EPROM programming algorithms, often only used in production programmers, take steps to verify correct programming at worst case supply voltages. They may also check the cell programming during the program operation so that a specific amount of over-programming is applied, but with new parts this is not necessary.

author: Konkedout
author_rank: Frequent Contributor
timestamp: May 18, 2025, 01:16:08 am
content: During the 1970s I worked for Data 100 corporation outside of Minneapolis MN. I had heard about a new printer design which worked until the cabinet was closed. Of course that only happens when you are done with the design.The designer had used some neon bulbs as trigger devices, and they worked OK when there was incident light. Without light, they did not trigger ON. So..you can guess what was the solution. They put a fluorescent lamp inside the cabinet. You can bet that customers wondered about that!!!

author: golden_labels
author_rank: Super Contributor
timestamp: May 18, 2025, 01:40:27 am
content: Semiconductors don’t care, if electrons come to them through a wire or from photons. Raspberry Pi 2 users learned that ten years ago, with adevice powering down when photographed. This is why all semiconductors are encased in dark epoxy or ceramics. Unless they’re meant to be used with light.Perhaps, by programming it with lights on, you made some biasing change? And now, when reading in the dark, the circuitry sees some values as higher/lower than they are intended to be?

author: wraper
author_rank: Unknown
timestamp: May 18, 2025, 01:44:05 am
content: Quote from: golden_labels on May 18, 2025, 01:40:27 amFar from all, usually does not matter if they're within enclosure. Diodes and Zeners in glass package are not protected from the light. Most of chip scale packages (WLCSP - bare die BGA) are not protected either, that'd why Rpi could be rebooted by light flash.QuoteWon't realistically happen. IMHO EPROMs were poorly erased as already suggested. Not to say this is not some QLC NAND where you need to distinguish between many charge levels.

author: David Hess
author_rank: Super Contributor
timestamp: May 18, 2025, 04:44:27 am
content: Quote from: Konkedout on May 18, 2025, 01:16:08 amThey make special neon bulbs which avoid that problem by having a small radioactive source within the envelope. Otherwise the start voltage changes with ambient illumination.

author: BrianHG
author_rank: Super Contributor
timestamp: May 18, 2025, 08:17:29 am
content: Quote from: titmouse001 on May 17, 2025, 06:01:32 pmIn the late 80s, I built my own programmer.Eprom addr in -> data valid out can optically vary if your programmer's VPP & VCC are weak or noisy during the burn, VPP switched high and low during programming, or after a valid program/verify pass, for some brands of eprom, you did not do the 4x burn time pass (Not all programmers do this one as it is only considered for production cases and slows the burning considerably).Some brands of eprom are less susceptible to these things.However, your problem smells more like poor erasing before programming.

author: forrestc
author_rank: Unknown
timestamp: May 18, 2025, 08:55:34 am
content: Quote from: Benta on May 17, 2025, 06:52:14 pmDo you have a datasheet that actually says this? I'd like to correct my personal belief if this is real.I've looked at quite a few datasheets online. They are consistent with my recollection from 35+ years ago to today... that is, you don't need to cover them during programming under normal lighting conditions. I even pulled a couple of printed databooks that didn't mention any need to cover the window during programming.In fact, a Motorola 2532 datasheet stated: "After erasure and programming of the EPROM, it is recommended that the quartz window be covered with an opaque self-adhesive cover". It says "after programming", not before...This thread is the first time I've ever heard the "cover before programming" recommendation, and I haven't been able to independently verify it anywhere I can find. The closest I got was a poorly phrased section in an MSP datasheet, which could be read either way - cover before or after programming.Like another poster, I've programmed (and seen programmed) LOTS and LOTS of EPROMS for production use where the programming was done first, and then the label was only added after the program and verify was done. The label indicated that the verification succeeded. This is a pretty typical production method. Now, they needed to be covered immediately after programming to avoid any possible slight erasure from ambient light.I also have done R&D using EPROMS, where you'd rotate a half dozen or so through the UV eraser (often burning your fingers in the process) and then debugging your code by programming an EPROM, inserting it into a socket, testing, and then if it didn't work, moving on to the next EPROM, and not once do I recall having a ambient light issue.

author: SteveThackery
author_rank: Super Contributor
timestamp: May 18, 2025, 09:13:41 am
content: Quote from: forrestc on May 18, 2025, 08:55:34 amThis is an excellent point, and in retrospect I realise that I misspoke - my apologies. Thinking back, I didn’t put labels on EPROMS until they had been programmed. I'm pretty sure I programmed them without the label so that if the verification stage failed there was never a chance of mistaking the EPROM for a properly programmed one.Certainly, though, I never had the situation described by the OP. That is truly bizarre and indicates something is definitely wrong.

author: pcprogrammer
author_rank: Super Contributor
timestamp: May 18, 2025, 10:02:11 am
content: I have used EPROM's in reasonable amounts back in the days that the MCU's did not have build in FLASH, and never encountered this phenomenon where it returns different data between being in the dark or receiving some ambient light.During programming no sticker on the EPROM, certainly not ones that I had to erase before using them again. Also during development of code, before I had an EPROM emulator, I did not cover them either. Only after finishing a project and sending it out for deployment, a sticker was put on the EPROM.Also for MCU's with a build in EPROM, I used the same method.So something smells fishy here. Maybe something else in the circuit that is causing this weird problem, seeing that it behaves the same with different EPROM's.Edit: There is not a lot of UV when not in direct sunlight, so even not having a sticker on them it did not fail that fast. Like titmouse001 wrote, it takes weeks in direct sunlight before it starts to erase. It also takes time to erase with a proper UV light, and that varies based on the quality of the light and the EPROM.

author: radiolistener
author_rank: Super Contributor
timestamp: May 18, 2025, 12:04:43 pm
content: the explanation with insufficient erasure before writing looks the most plausible, i.e. the cells were poorly erased and are on the border of zero and one, and a little lighting is enough to shift them in one direction or another and get a different value.

author: RoGeorge
author_rank: Super Contributor
timestamp: May 18, 2025, 12:24:47 pm
content: First I would suspect will be the lights, probably they are producing some extra EMI when turned off?Try disconnecting the lights from mains. Don't just turn them off, unplug the lights completely.Does the weird behavior still happens with natural lights?

author: coromonadalix
author_rank: Super Contributor
timestamp: May 18, 2025, 01:19:48 pm
content: and some programmers can or could not issue the right programming voltage(s) some do ask 12.5v 21v or 25v ??even if you select say a : 27c256 you have tons of brand and makers, and some could have subtle differencesid did found out, some need the uv erase, and done electrically its not good and fail crc error checks ?i use uv box to erase the windowed ones, and always put a black tape or metallic one once done

author: titmouse001
author_rank: Newbie
timestamp: May 18, 2025, 01:26:40 pm
content: Just tried with a freshEPROMwith sticker before burning - no luck. Data is still getting corrupted. As usual, I tested a second board with the same result. I had a moment when I removed the sticker and it still didn’t work - turned out it was just the window, it was all gummed up. After cleaning off the residue, it started working!In a dark room, shining a hand torch on it makes it work- thisstrongly suggeststhat light is affecting the EPROM’s behavior!I trying digging out the old S4 Dataman programmer as well,(I'm currently a using USB - XG ecu). I’m keen to get to the bottom of this - needing to shine a light into an EPROM to make it work inside a closed box would be... unusual. Maybe increasing the erase times. I do verify all EPROMs after blanking, since I do them in large batches.Here’s a link to my project - maybe someone can spot something obvious that I’ve overlooked!https://github.com/titmouse001/ZX-Spectrum-48k-Arduino-Interface

author: wraper
author_rank: Unknown
timestamp: May 18, 2025, 01:51:53 pm
content: Quote from: titmouse001 on May 18, 2025, 01:26:40 pmWhy do you think your EPROM is fresh? If you got them from China, there is 95+% chance those are used chips, usually with old marking erased and new marking applied, likely with altered speed grade. Might be even a similar EPROM from different manufacturer.

author: wraper
author_rank: Unknown
timestamp: May 18, 2025, 01:55:35 pm
content: Another possibility is that some EPROM input is left floating.

author: BrianHG
author_rank: Super Contributor
timestamp: May 18, 2025, 02:09:48 pm
content: Quote from: wraper on May 18, 2025, 01:55:35 pmOr, poor continuity to a pin. Like a series 100k.Or, noisy VCC. Poor decoupling.An open VPP pin could alter output timing.

author: nfmax
author_rank: Super Contributor
timestamp: May 18, 2025, 02:54:56 pm
content: Is your EPROM programmer still in calibration? Does it use the official algorithms specific to the manufacturer, device, and mask revision? (and have you set these correctly?) Does it do full marginal verify after programming? Does it do a full marginal blank check before programming?This has all the hallmarks of a poorly programmed and/or erased chip!

author: RoGeorge
author_rank: Super Contributor
timestamp: May 18, 2025, 04:49:06 pm
content: In EPROMs everything is exposed to light, address decoders, analog amplifiers for each data line, buffers, all the circuits inside the EPROM, not only the memory cells. Direct light induces voltages by photoelectric effect. So, external light may act like some sort of analog bias voltage.I would double check the voltages, +5V and +12V during writing, and also check the +5V during reading. Double check there are no spikes and noises.Also, double check for firm contacts on the pins. It is easy to spot bad contacts while looking with an oscilloscope (preferably analog) at the address/data/CS lines, while a program is running. The pins with bad contacts usually will appear more "muddy" on the oscilloscope, or shifted, when compared with other pins of a similar type.

author: titmouse001
author_rank: Newbie
timestamp: May 18, 2025, 05:21:23 pm
content: Burned a new test now with a Dataman S4 shows the same issue (needs ambient light).I source all my EPROMs for free from old pro gear, erase and verify each one.Testing different brands, speeds, and sizes all show the same odd behavior - even when tested with spare prototype boards.Both the Dataman and a cheap XG programmer can read EPROMs from each other just fine with the window covered - so is this pointing to my circuit?The EPROM connects via the expansion port to the ZX Spectrum 48K. Both a stock unit and a Harlequin board show the same issue, though EPROMs read fine in both programmers.I'm very confused - My circuit is here:https://github.com/titmouse001/ZX-Spectrum-48k-Arduino-Interface

author: titmouse001
author_rank: Newbie
timestamp: May 18, 2025, 07:55:48 pm
content: Looks like I'm doing something silly. I just rigged up a picture test card on an EPROM - it shows the image fine, and when wired this way, everything works.I'm thinking the issue might be with my A14 upper/lower ROM selector or the /CE IC logic, since I have two ROM binaries on one EPROM.It feels like a timing issue when switching between the ROMs.Thanks for all help, like floating linesHopefully, I’ll have time to look into this over the next few weeks. I’ll report back if I find the issue.

author: CaptDon
author_rank: Super Contributor
timestamp: May 18, 2025, 08:04:06 pm
content: If the eproms still verify correctly on your programmer but fail to work properly in your project I highly suspect your eprom cycle times are messed up in your arduino coding. Light may possibly effect access time OR the deselect tri-state time!!! If the eprom verifies correctly in light or dark then your problem is in your homebuilt circuitry or the timing!! I don't think anyone else has suggested this solution. What is the access times on your eproms?? are they -15, -20, -25 versions? the -25 would have a 250ns access time and certain factors could nearly double that figure!! You need a scope!!

author: floobydust
author_rank: Super Contributor
timestamp: May 18, 2025, 09:01:32 pm
content: Signal "_UpperROM" on A14 might have too much delay on it. It's read-modify-write I believe from your code in Pin.h:#define WRITE_BIT(reg, bit, val) _INTERNAL_WRITE_BIT_##val(reg, bit)#define _INTERNAL_WRITE_BIT__HIGH(reg, bit) ((reg) |= _BV(bit)) // SET#define _INTERNAL_WRITE_BIT__LOW(reg, bit) ((reg) &= ~_BV(bit)) // CLEARPlus the two-gate delay for the EEPROM CE via a 74HC32 seems to be ~20-40nsec lost as well.

author: BrianHG
author_rank: Super Contributor
timestamp: May 18, 2025, 11:43:16 pm
content: Quote from: floobydust on May 18, 2025, 09:01:32 pmInstead of CE, keep the eprom enabled and use the OE instead to save the address setup time, especially on the slower eproms.

author: 5U4GB
author_rank: Super Contributor
timestamp: May 19, 2025, 12:07:24 am
content: Quote from: CaptDon on May 17, 2025, 10:04:46 pmThey also slowly get erratic on cells reads over time as thresholds shift. I've got a device with a 1702A in it that randomly reads some bits as a zero or one on every scan of the values despite being in a dark cabinet since it was programmed.

author: CaptDon
author_rank: Super Contributor
timestamp: May 19, 2025, 02:14:35 am
content: Brian is right on about keeping the chip enabled CE and using OE to control the output!! 5U4, I think the 1702's and most made shortly there after like the Intel 2708/2716 25 volt programming versions said '10 year data retention'. I had an Intellec 8MOD80 that had a built in front panel 1702A programming socket!! I believe Christopher Titus bought the unit from me at the Gaithersburg Maryland Hamfest to put it in his museum.

author: floobydust
author_rank: Super Contributor
timestamp: May 19, 2025, 02:24:54 am
content: I'm not fully sure how OP's project works, it looks like an Arduino Nano middleman between a 27C256 and the ZX Spectrum 3.5MHz Z80. 286nsec Tstate but Sir Clive's always cute with the variable number of wait states. I'm not a ZX Spectrum expert.https://worldofspectrum.org/faq/reference/48kreference.htmI was just trying to see if there's enough time or it's just too tight and light helps the access time.

author: EEVblog
author_rank: Unknown
timestamp: May 19, 2025, 03:53:16 am
content: Are there any pins floating in the design or construction?

author: pcprogrammer
author_rank: Super Contributor
timestamp: May 19, 2025, 06:29:30 am
content: Quote from: floobydust on May 19, 2025, 02:24:54 amThe way I read the circuit, is that the EPROM is just connected to the ZX Spectrum, and the Arduino Nano only controls a select between two regions of the EPROM. The Arduino Nano can only send data to the ZX Spectrum via the databus when, on the ZX Spectrum, an IO read is done with address line A7 being low.The control of the two regions is done with the signal _UpperROM, coming from pin A1 on the Nano. It depends on the setup in the Nano if it is actually a push pull output. When not configured it will be an input and thus floating. Might be best to add either a pull down or pull up to that signal.The EPROM is accessed on a memory request and A15 and A14 being low. Not familiar with the ZX Spectrum, so not sure if a memory request is only active on a read. If not, there could be bus contention in case of a write to that address region.

author: titmouse001
author_rank: Newbie
timestamp: May 19, 2025, 01:06:14 pm
content: Thanks for the suggestions!I like the /CE, /OE idea; it's low-hanging fruit that I can find some time to give a go tonight. Makes sense that chip designers would give /OE preference on timings.(The EPROM is directly connected to the Z80 bus, enabled/disabled via simple OR logic using the Z80's /A14 OR /A15 OR /MREQ lines, so it does not interfere with the CPU when it's using the RAM)

author: titmouse001
author_rank: Newbie
timestamp: May 19, 2025, 05:44:58 pm
content: Swapping EPROM /CE and /OE didn’t helpThing is, everything works - load game from SD, send to Spectrum, play, back to menu, pick another, repeat. ROM disables in time, so /MREQ and /RD seem fine.Maybe data lines clashing… but it’ll run for hours cycling SNA files with no issues. Rock solid.Feels like an edge case. Gonna have to think it through - limited to finger-poking diagnostics, no oscilloscope.

author: floobydust
author_rank: Super Contributor
timestamp: May 19, 2025, 06:40:47 pm
content: It's seems weird the problem you are having.So you could take the Arduino right out of the picture, just connect the bank select _UpperROM signal to power or GND and see if things work.The PCB design ground-pour does not look great to me. It's sliced up, almost nothing for via's so I would expect some noise there.The critical through-hole pins (EPROM pin 14, two pin header) I would make sure solder flowed through between top and bottom of the board. I would add a direct (through-hole) decoupling cap for the EPROM across pins 28/14, because the ground for that cap right now is a mile or two away, too far away- if you follow the pour.Usually you will find bulk capacitance 10-100uF present as well on a card. If this is a power quality problem.

author: EEVblog
author_rank: Unknown
timestamp: May 19, 2025, 10:46:22 pm
content: Quote from: titmouse001 on May 18, 2025, 07:55:48 pmSounds like the light is a red herring.

author: titmouse001
author_rank: Newbie
timestamp: May 21, 2025, 08:36:32 pm
content: Found the problem - it was the power supply.I didn’t suspect it at first, since it’s old but good quality: a FW74010/09 9V 1.2A power supply.With this power supply, the EPROM needed a small amount of light exposure to overcome switching noise - or maybe it’s just due to the age of the power supply, I’m not sure.Using a bench power supply solves the issue completely. I can press my thumb firmly over the EPROM and it keeps working. With the faulty supply, doing the same would instantly corrupt the data!Thanks everyone for the help- it was a very odd issue. The light making it work was just a strange side effect, but it helped point to the real problem!