More EPROM stuff

You might want to consider reading the originals several times, and check for differences (MD5 checksum would work, diff will give more detail), to detecf soft failure. Reading doesn't incur any 'wear out' risk, and the best probability is that the most-often-read pattern is the correct data.

I'm not sure how to check one read from another. The programmer software has a command called verify that somehow "verifies" the information written to the EPROM. I don't see a checksum command. I suppose I could save the program in the buffer as a text file and compare the text files. Do you have any suggestions? Is MD5 checksum a program I can download? Thanks, Eric

te:

l),

at the most-often-read

That even happens with modern 25 series eeproms. I record the eeprom then verify it back using the programmer's software. If I get any errors, I kee p copying it until the copy I have matches the .bin on the eeprom. Once I get a verified copy, I delete the others.

The usual programmer software (last one I used supported Motorola S-format but decades pass) can make a binary or hexadecimal dump file, with no extraneous info (date/time, for instance). It's a nuisance to proofread one such file against another, so one would make a checksum; the MD5 algorithm can hash large files down to 128 bits, and match of such hashes implies bit-by-bit match of files, or even directories of files. There's lots of utilities that can do such a hash, I've found 'em for Windows.

The 'verify' function tests a programmed unit against a file. What I was suggesting, was comparison of twenty dumps from the elderly unit against each other, to see if there were 'weak' bits.

The reason to retain twenty copies, is to pick the most-likely-to-be-correct bit values if there IS a difference found, and the verify might not give enough detail in its report. A checksum that's the same 17 times in 20 is probably indicative of the 'right' data.

I suggest using the verify function on the programmer several times, however you release and then tighten the ZIP lock-lever prior to each verify.

Good quality programmers (like the Xeltek SP-610P) have a handy feature that allows for verify to be done at 5% below and above the 5.00 Vcc. I enable that by default because every now and then it catches a bad chip.

John :-#)#

Eric, The "Verify" feature doesn't compute a checksum for the data. After the device is programmed, the Verify simply reads the contents of the device and compares it, bit by bit, with the original data file.. If the contents of the device are the same as the original data file, then the device is verified as being successfully programmed. It's usually a good idea the run the verify function 3 or 4 times, just to be absolutely certain that the device has the correct data. If the verify function returns an error, that means that the device either didn't accept the data correctly, it might have not been completely erased, or it might just be a bad device. Cheers, Dave M

It seems to me that the best way to test the chips after programming and using the verify function is to just place them back into the machine and make sure the machine runs correctly. If the machine functions all work then the chip must be good. But I will run the verify test a few times on each chip just for luck. Eric

My only piece of advice: Always double check the orientation of the chip in the socket when you are putting it into the machine. It is very frustrating to see through the window the brief incandescence from the melting VDD bondwire.