| Author |
 Topic  |
|
|
macgyver655
14 Posts |
 Posted - 01/04/2008 : 13:50:57
|
| I'm having trouble trying to backup some AT29C010 15JC ic's I have. The manufacture went out of business over 10 years ago so I'm trying to save some copies. I have the GQ-3x programmer. I seem to be able to save a good copy because the checksum is the same as the lable on the ic. I have about 5 chips from the same company, just different models. The problem is when I try to write to a blank chip, the verify fails at address 0x000080, and I end up with a different checksum. I tried on 2 different blanks and same results. If I save a copy of the bad write and then write that bin, it is sucessful and that checksum is the same, but naturally not the correct bin. What I have noticed is that on a failed write, the first 8 lines of code and the next 8 lines are the same, then the next 8 lines are the same as the next 8 lines and so on. This is not so on the original bin. Is this some sort of copy protection? Thanks |
|
| Reply #1
ZLM
2945 Posts |
Posted - 01/05/2008 : 09:39:16
|
| It seems you have pin 5 contact issue. Check chip pin 5 is contacted well with ZIF socket. If you have any other chip for testing, just give a try. So that to eliminate the chip problem. |
 |
|
| Reply #2
macgyver655
14 Posts |
Posted - 01/05/2008 : 09:47:38
|
| The blanks I have are PLCC style and I'm useing the 32PLCC to 32 dip adapter. I have tried 2 different blanks with the same results. I have also erased them after a bad write and retried with the same results. Also as I stated in the post, If I save a copy of the bad write, then erase the chip and then flash again with the bad copy, the write is sucessful.I was going to see if I have a bin from something other then this device to see if a bin from a different source will write sucessfully. |
|
|
| Reply #3
macgyver655
14 Posts |
Posted - 01/05/2008 : 19:34:08
|
| Ok. I tried a bin from a different device and it again duplicated the 1st 8 lines to the next 8 lines and so on. So I tried an experiment and F'ed out the chip and verified as blank. I then typed data on line 00000000 and wrote that to the chip.The verify failed at line 00000080.That line now also contained a duplicate of line 00000000. I then F'ed it again, verified blank, and typed data on line 00000010 and wrote it. Verify then failed at line 00000090. The same data was now on line 00000010 and line 00000090. I then tried uninstalling the software and removing all traces of it, then reinstalled software and tried again with the same results. Seems like a problem with the programmer. Any comments? |
|
|
| Reply #4
macgyver655
14 Posts |
Posted - 01/06/2008 : 07:46:27
|
| As you can see in my 2nd post, I'm using the 32PLCC to 32Dip adapter. |
|
|
| Reply #5
ZLM
2945 Posts |
Posted - 01/06/2008 : 10:11:25
|
adapter problem?
Can you check if there are any short pins or open pins on the adapter? |
|
|
| Reply #6
macgyver655
14 Posts |
Posted - 01/06/2008 : 19:46:53
|
OK. I tested the pins accordings to the data sheet and they tested good for continuity and proper location. I then tested for a short on each pin to all others one at a time and tested ok. Just to be sure to rule out the adapter, I looked at the contacts in the PLCC socket with a magnifier and some looked in a little far. So I made a device to catch the contact and pull them out a little and did each pin until they all looked to protrude enough. I then put in a chip, verified as blank and wrote a bin to it.Bingo. It verified good. I then read the chip and the checksum was valid. I then tested the chip in the device and it worked perfectly. I then tried another chip and it was successful as well.
Apparently it was one or more of the contacts in the PLCC socket. Glad this problem is solved. Thanks for all suggestions. |
|
|
| Reply #7
ZLM
2945 Posts |
Posted - 01/08/2008 : 09:51:56
|
| Yes. Some chips may get poor contact if the chip is pushed too deep in the PLCC socket. |
|
|
| |
Topic |
|
AT29C010 Problem
Forum Locked
