More EPROM stuff

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
   First of all I'd like to say thanks to everyone who replied to
myprevious EPROM posts. I think I responded to everyone but I am a bit
scatter-brained and I miss stuff.
   Now on to the good stuff. I bought the GQ-4x4 Universal Programmer.
For a hundred bucks including shipping it seemed like a good deal. In
the box was not only the programmer itself but also the USB cable, an
EPROM puller, and 3 adapter boards for SOP 17-1.27, PLCC32, and PLCC32
for 27C64-27C512 devices.
 I hadda also buy a UV eraser but I found a cheap one that works just
fine. After all I only need to 6 EPROMs, but I will be making several
copies so maybe 24 EPROMs total.
    But the best part is the copy process. I inserted an erased chip
to check if it was blank and it was. So in goes the chip to copy. it
gets read and then I swap in the blank chip and program it. Just had
to click the write button. So easy.
   In a couple weeks the machine will have a window of time where I
can do the copying of the chips particular to this machine. then I can
test the copies and if they work I'll keep the originals in a safe
place and just use the copies.
Eric

Re: More EPROM stuff
On Saturday, December 7, 2019 at 10:20:48 AM UTC-8, snipped-for-privacy@whidbey.com wrote:

Quoted text here. Click to load it


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.

Re: More EPROM stuff
wrote:

Quoted text here. Click to load it
   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

Re: More EPROM stuff
On Saturday, December 7, 2019 at 4:06:57 PM UTC-8, snipped-for-privacy@whidbey.com wrote:
Quoted text here. Click to load it



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.

Re: More EPROM stuff
On 2019/12/07 5:53 p.m., whit3rd wrote:
Quoted text here. Click to load it

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 :-#)#

Re: More EPROM stuff
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


On Sat, 07 Dec 2019 16:06:55 -0800, snipped-for-privacy@whidbey.com wrote:

Quoted text here. Click to load it

Re: More EPROM stuff
On Tue, 10 Dec 2019 17:46:03 -0600, Dave M <dgminala at mediacombb dot
net> wrote:

Quoted text here. Click to load it

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

Quoted text here. Click to load it


Re: More EPROM stuff
On Saturday, December 7, 2019 at 6:21:41 PM UTC-5, whit3rd wrote:
Quoted text here. Click to load it
te:
Quoted text here. Click to load it
l),  
Quoted text here. Click to load it
at the most-often-read
Quoted text here. Click to load it

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.

Re: More EPROM stuff
On 08/12/2019 05:20, snipped-for-privacy@whidbey.com wrote:
Quoted text here. Click to load it

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.


Site Timeline