eprom failure modes

I came across a new one today: eprom (27c512) programs fine, verifies fine, runs like crap. lots of errors. Same code in an emulator runs fine. Same code read back into the programmer and verified again fine. Same code in another physical 27c512 chip runs fine (same target board). What could the chip be doing differently when plugged into the target board vs. the programmer?

Reply to
Fritz Oppliger
Loading thread data ...

Could be slow access time.

John

Reply to
John Larkin

Try verifying with slight variations in the supply voltages. Also see if it's giving you good logic-level voltages on the outputs.

Reply to
Michael A. Covington

Is this one of those chips that have a window for erasure? Is light shining on the chip?

--
John Popelish
Reply to
John Popelish

Yes, UV erasable, with window. But there really is not much light in here. There is a plain white paper label stuck on the window, proudly proclaiming the version number I gave it. I have done many hundreds of Eproms but so far they either worked or failed to program/ verify. I'll chalk this one up to some subtle (ESD?) degradation that affects its speed. And I may throw it away. Or I may keep it for some future forensic need (with all the other stuff awaiting the same unlikely day...)

Are you suggesting trying it out with a light-impermeable label on it? I can try that.

Reply to
Fritz Oppliger

Assuming your board is designed well, just throw the darned thing away. They are cheap to replace.

Jon

Reply to
Jonathan Kirwan

Hi, Fritz. First look at the numbers after the 27C512. You might find something like -15 (meaning 150 ns access time). If the number is different on the two ICs you have, that would be the primary suspect. If the numbers are the same, look at replacing with a faster access time 27C512. If the design is right on the edge with data access times, one IC could work and another not, but both of them meet the spec. This is the type of problem that requires muscling through all the data sheets for worst case specs on processor, glue logic if present, and EPROM on memory reads, then doing the maths. Not easy, but there it is. You'd be astounded, but sometimes engineers spec memory chips based on typical times and crossed fingers rather than worst-case. If that solves the problem, you're good to go. Also look to see if one IC in the CPU-to-memory chain has been replaced by another possibly slower one on the board.

If none of these work, it could just be a defective EPROM.

Good luck Chris

Reply to
CFoley1064

If you have a label over the window, then light is probably not the problem. But you should be aware that light definitely messes up the operation of these devices, and they should be kept in dim light or darkness during the programming and verification process, as well as when in use.

--
John Popelish
Reply to
John Popelish

I'm voting for this explaination. I have had it happen in the past. I have yet to see a programmer that actually tests the part ANYWHERE near the speed the part should be capable of. The programmer is probably operating in the high microseconds not nanoseconds.

Jim

Reply to
James Beck

"John Larkin" wrote in message news: snipped-for-privacy@4ax.com...

Another possibility is that the part has been stressed with ESD or some other operating condition. EPROM programmers do not run the part at full speed so it may pass in the programmer and fail in the target. It sounds like we're talking about a single EEPROM here - chuck it out!

Reply to
Dana Raymond

EPROM. clunk.

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Reply to
Fritz Oppliger

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.