MCUmall EPROM BIOS Chip Burner Forum
MCUmall EPROM BIOS Chip Burner Forum
Home | Profile | Register | Active Topics | Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 MCUmall Forums
 True USB Willem Programmer (GQ-2X,3X,4X & GQ-4x4)
 gq 4-4 writing error with larger eproms

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Screensize:
UserName:
Password:
Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List Spell Checker
   
Message:

* HTML is OFF
* Forum Code is ON
Smilies
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

   Insert an Image File
Check here to include your profile signature.
    

T O P I C    R E V I E W
harig 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
15   L A T E S T    R E P L I E S    (Newest First)
harig Posted - 04/05/2024 : 09:47:03
That's why I'm stuck...
anniel 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.
harig 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
anniel 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.
harig 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?

anniel 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.
harig 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)
anniel 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.
harig 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
anniel 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.
harig 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???
harig 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


anniel 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.
harig 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
anniel 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?

MCUmall EPROM BIOS Chip Burner Forum © Copyright 2003 - 2009 Mcumall Electronics Inc. Go To Top Of Page
Generated in 0.07 sec. Snitz Forums 2000