| Author |
 Topic  |
|
|
harig
9 Posts |
 Posted - 03/28/2024 : 07:48:18
|
my programmer recently developed some issues:
In the past I had no issues programming different types of 27C040, M27C4001, TMS27C040 and other even larger Eproms
When burning yesterday some M27C512 eproms all worked fine without issues but the M27C4001 will always fail during writing at the exact same position/address: 26,58% / 0x022001
- all eproms were blank checked before
- tested with slower speed (0 instead of default +2)
- updated firmware with the latest version 7.32
- tested different USB ports (2.0 , 3.0) on the laptop
- tested with additional external power supply
- voltage dignostic: all tests passed
- used different device profiles (27C040, M27C4001, TMS27C040) to program the chip
- tested at least 15 different eproms (some of them were successfully programmed in the past already)
As the programming always fails at the same address I verified the hex files from eprom and noticed following:
starting from address 0x22000 the data written into the eprom is not the same as shown in the buffer at the corresponding address . Instead starting from address 0x22000 the data read from the eprom is the same as located at address 0x2000 - note the offset!
It seems to me that address line A17 is involved in that issue causing that the data from 0x2000 onwards gets duplicated at address 0x22000 onwards.
Till address 0x21FFF all seems fine and from 0x22000 the duplication starts
Does my programmer have issues with adress decoding?
I used the "test H/w" functionality to toggle the states of all the pins of the programmer - even A17 seems fine and toggles betwenn 0V and 3,3V like all the other adress lines. When starting a blank check one can also see some traffic on A17 (toggling between 0V / 3.3V) which leads to the estimation that A17 should be ok.
What I noticed during those H/W tests that D6 and D7 only provide 3,8V when high while all the other data pins D0 - D5 provide 4,8V
Could that be my issue?
opened the programmer to check-except for quite some flux left from production I could not see anything obvious. Tried to follow the signal paths which is not that easy without schematics
Any idea what is causing my "duplication" of data at the wrong address?
thanks
|
|
| Reply #1
anniel
2572 Posts |
Posted - 03/28/2024 : 09:53:17
|
quote:
Originally posted by harig
my programmer recently developed some issues:
In the past I had no issues programming different types of 27C040, M27C4001, TMS27C040 and other even larger Eproms
When burning yesterday some M27C512 eproms all worked fine without issues but the M27C4001 will always fail during writing at the exact same position/address: 26,58% / 0x022001
- all eproms were blank checked before
- tested with slower speed (0 instead of default +2)
- updated firmware with the latest version 7.32
- tested different USB ports (2.0 , 3.0) on the laptop
- tested with additional external power supply
- voltage dignostic: all tests passed
- used different device profiles (27C040, M27C4001, TMS27C040) to program the chip
- tested at least 15 different eproms (some of them were successfully programmed in the past already)
As the programming always fails at the same address I verified the hex files from eprom and noticed following:
starting from address 0x22000 the data written into the eprom is not the same as shown in the buffer at the corresponding address . Instead starting from address 0x22000 the data read from the eprom is the same as located at address 0x2000 - note the offset!
It seems to me that address line A17 is involved in that issue causing that the data from 0x2000 onwards gets duplicated at address 0x22000 onwards.
Till address 0x21FFF all seems fine and from 0x22000 the duplication starts
Does my programmer have issues with adress decoding?
I used the "test H/w" functionality to toggle the states of all the pins of the programmer - even A17 seems fine and toggles betwenn 0V and 3,3V like all the other adress lines. When starting a blank check one can also see some traffic on A17 (toggling between 0V / 3.3V) which leads to the estimation that A17 should be ok.
What I noticed during those H/W tests that D6 and D7 only provide 3,8V when high while all the other data pins D0 - D5 provide 4,8V
Could that be my issue?
opened the programmer to check-except for quite some flux left from production I could not see anything obvious. Tried to follow the signal paths which is not that easy without schematics
Any idea what is causing my "duplication" of data at the wrong address?
thanks
Are all EPROM from the same batch? |
 |
|
| Reply #2
harig
9 Posts |
Posted - 03/28/2024 : 11:54:14
|
different eproms from different sources and manufacturers were tested.
Some of them were successfully programmed in the past already |
|
|
| Reply #3
anniel
2572 Posts |
Posted - 03/28/2024 : 12:21:21
|
quote:
Originally posted by harig
different eproms from different sources and manufacturers were tested.
Some of them were successfully programmed in the past already
Looks like an address line issue. |
|
|
| Reply #4
harig
9 Posts |
Posted - 03/28/2024 : 12:51:55
|
indeed- my latest finding so far: I go into Test H/W mode where one can set individual adresses.
when I set A13 to high (3.3V) A17 also goes to high although not activated. The other way around A17 high, A13 stays low as expected.
Setting just A17 high/low also works
seems there is some connection or other issue from A13 to A17 - ohmic measurement between those pins is fine and same as between other adresspins
|
|
|
| Reply #5
harig
9 Posts |
Posted - 03/28/2024 : 13:59:58
|
I isolated the two outputs A13+A17 at the CPLD (U6) - the 'crosstalk' from A17 to A13 already happens there - so no easy replacement of a diode or similar...
could the issue already happen at the input of the CPLD ??
or am I completely wrong and it is something else, e.g. a software issue??? |
Edited by - harig on 03/28/2024 14:16:56 |
|
|
| Reply #6
anniel
2572 Posts |
Posted - 03/29/2024 : 05:25:11
|
quote:
Originally posted by harig
I isolated the two outputs A13+A17 at the CPLD (U6) - the 'crosstalk' from A17 to A13 already happens there - so no easy replacement of a diode or similar...
could the issue already happen at the input of the CPLD ??
or am I completely wrong and it is something else, e.g. a software issue???
Hard to tell if it's internal chip damage or software but seing the voltage discrepancies I think the CPLD is bad. |
|
|
| Reply #7
harig
9 Posts |
Posted - 03/30/2024 : 10:48:40
|
| So it seems I have an expensive paperweight after only 3 years and seldom use...sad that it is not repairable |
|
|
| Reply #8
anniel
2572 Posts |
Posted - 03/31/2024 : 06:56:36
|
quote:
Originally posted by harig
So it seems I have an expensive paperweight after only 3 years and seldom use...sad that it is not repairable
It would be interesting to find out the root cause of the trouble. |
|
|
| Reply #9
harig
9 Posts |
Posted - 04/01/2024 : 10:50:33
|
I agree
I used the programmer some weeks ago without any issues and now it is not working anymore with bigger ROMs.
I almost certainly can exclude that I destroyed it by any misuse (if that would be even possible) |
|
|
| Reply #10
anniel
2572 Posts |
Posted - 04/02/2024 : 05:50:51
|
quote:
Originally posted by harig
I agree
I used the programmer some weeks ago without any issues and now it is not working anymore with bigger ROMs.
I almost certainly can exclude that I destroyed it by any misuse (if that would be even possible)
A possible cause could be a bad EPROM chip. |
|
|
| Reply #11
harig
9 Posts |
Posted - 04/03/2024 : 13:06:36
|
quote:
Originally posted by anniel
quote:
Originally posted by harig
I agree
I used the programmer some weeks ago without any issues and now it is not working anymore with bigger ROMs.
I almost certainly can exclude that I destroyed it by any misuse (if that would be even possible)
A possible cause could be a bad EPROM chip.
I bought a different programmer and re-tested those eproms I had tested with my now faulty gq4x4 some time ago - those eproms tested all fine in my new programmer. They were also small size (27C512) that do not use the faulty address line A17 so they still work in my faulty gq4x4. I assume that those eproms did not kill my gq4x4.
I can see quite an amount of diodes in my gq4x4-maybe they are for protection of the programmer just in case?
|
|
|
| Reply #12
anniel
2572 Posts |
Posted - 04/04/2024 : 06:23:32
|
quote:
Originally posted by harig
quote:
Originally posted by anniel
quote:
Originally posted by harig
I agree
I used the programmer some weeks ago without any issues and now it is not working anymore with bigger ROMs.
I almost certainly can exclude that I destroyed it by any misuse (if that would be even possible)
A possible cause could be a bad EPROM chip.
I bought a different programmer and re-tested those eproms I had tested with my now faulty gq4x4 some time ago - those eproms tested all fine in my new programmer. They were also small size (27C512) that do not use the faulty address line A17 so they still work in my faulty gq4x4. I assume that those eproms did not kill my gq4x4.
I can see quite an amount of diodes in my gq4x4-maybe they are for protection of the programmer just in case?
Bad diodes could also be loading some lines. |
|
|
| Reply #13
harig
9 Posts |
Posted - 04/04/2024 : 12:13:43
|
| I cut the traces of A13 and A17 just after the CPLD to exclude any influence of other components-so no bad diodes in that case |
|
|
| Reply #14
anniel
2572 Posts |
Posted - 04/05/2024 : 08:39:03
|
quote:
Originally posted by harig
I cut the traces of A13 and A17 just after the CPLD to exclude any influence of other components-so no bad diodes in that case
That would tend to confirm a bad CPLD. |
|
|
| Reply #15
harig
9 Posts |
Posted - 04/05/2024 : 09:47:03
|
| That's why I'm stuck... |
|
|
| |
Topic |
|
gq 4-4 writing error with larger eproms
