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: 640 x 480 800 x 600 1024 x 768 1280 x 1024 UserName: Password: Format Mode: Basic  Help  Prompt  Format: Font Andale Mono Arial Arial Black Book Antiqua Century Gothic Comic Sans MS Courier New Georgia Impact Lucida Console Script MT Bold Stencil Tahoma Times New Roman Trebuchet MS Verdana   Size 1 2 3 4 5 6   Color Black Red Yellow Pink Green Orange Purple Blue Beige Brown Teal Navy Maroon LimeGreen Message: * HTML is OFF * Forum Code is ON Smilies [quote][i]Originally posted by mohhingman[/i] [br]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 [/quote]    Insert an Image File Check here to include your profile signature.