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)
 MX29L3211MC Verify issue

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
mohhingman Posted - 03/06/2013 : 22:06:33
Hello,

May I have some assistance? I have the ADP-019 and GQ-4X/v6.21 installed. I'm attempting to burn a 32MBit image to an MX29L3211MC. I'm experiencing an issue where bytes with the data 0x00 are randomly read back as other data after writing during verify. If I click verify again, the corrupt bytes can sometimes appear as a different sector. The ID checks out fine and the blocks are all unprotected. It seems to be mostly on the F offset the corruption occurs but sometimes the E offset. Reading the data in(not2.bin) and doing a compare of the original file(32m.bin) commonly looks like:

Name of first file to compare: 32m.bin
Name of second file to compare: not2.bin
Option:
Comparing 32m.bin and not2.bin...
Compare error at OFFSET 7FEFF
file1 = 0
file2 = 40
Compare error at OFFSET 7FF6F
file1 = 0
file2 = F0
Compare error at OFFSET BFF7F
file1 = 0
file2 = B9
Compare error at OFFSET DFF7F
file1 = 0
file2 = 60
Compare error at OFFSET EFFFF
file1 = 0
file2 = 40
Compare error at OFFSET FFFDF
file1 = 0
file2 = 90
Compare error at OFFSET 10FF7F
file1 = 0
file2 = 8
Compare error at OFFSET 11FE7F
file1 = 0
file2 = F0
Compare error at OFFSET 11FEFF
file1 = 0
file2 = E0
Compare error at OFFSET 11FF3F
file1 = 0
file2 = C0
10 mismatches - ending compare

~

As it can be seen, the problem only affects bytes with 0x00 as the data. They are 0x00 in the file to be burned and read back as other random data. I have tried changing the speed to -2, checking the pins continuity with multimeter and changing chips(have been cycling through 8 different MX29L3211MX's and swapping them after each failed attempt and erasing before writing). Is there a way to try read the chip even slower if speed is the problem? I've also tried using a different USB port and using an external 9V power supply, all seem to have no effect. Have you seen this phenomenon before, is there something i'm doing wrong?

Regards
Mark



4   L A T E S T    R E P L I E S    (Newest First)
mohhingman Posted - 03/09/2013 : 01:03:30
Hi All,

I found the problem. The ADP-019 adapter board had a faulty solder joint on R4, a 2k2 resistor. I've flowed some solder onto it and the chip verified first go. The resistor looks like it ties a line to VCC, so I guess that pin it was supposed to be pulling up on the MX29L3211 was floating and causing corruption errors. I'm glad now, can get on with my project.

Pics of solder joint before fix shown below:

Cheers
Mark

Image Insert:

86.05 KB

Image Insert:

82.84 KB
mohhingman Posted - 03/08/2013 : 22:30:55
Thanks Bad and ZLM for replying. I'l try programming on another machine and decoupling with 100nf caps and post results later.
Bad_Ad84 Posted - 03/08/2013 : 06:47:16
I use these chips with another programmer. I often need to use a 100nf cap between VCC and GND as close to the chip as possible to get them to act correctly.
ZLM Posted - 03/07/2013 : 20:35:29
From my experience., this is compatibility related or power noise related.

Make sure your VCC jumper on adapter is setting correct.

Also, check if you have strong electromagnetic field arround.

Is it never be verified after write? even once?

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