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?
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.
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.
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.
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.
"John Larkin" wrote in message news: email@example.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!