| T O P I C R E V I E W |
| stevenc |
Posted - 09/03/2011 : 18:33:37
Trying to program some am29f032 and so far no dice.
Using Gq-3x and ADP-077 and ADP-82.
Extra address lines are there.
Device added to the device list using this:
Name="AM29F032B*TSOP40",ID="0141",Class="29F040B",Category="FLASH",MFG="AMD",CodeSize="4194304",DIP="100011110101",Adapter="TSOP40B-DIP32(ADP-077 and ADP-082)";
Software v6.11
ID check ok
Erase ok
Blank check ok
Write ok
But it always fails right away to verify.
I tried reseating the chip, used different chips (same type/mfg), tried to switch J5 between v1 and v2.
I read what it wrote to the chip and compared it in an hex editor and the bulk of the code was correct but of course with a few bits that differed.
Same results with v6.13 |
| 41 L A T E S T R E P L I E S (Newest First) |
| ZLM |
Posted - 02/15/2012 : 10:11:29
Another related totpic:
http://www.mcumall.com/forum/topic.asp?TOPIC_ID=4510 |
| rkrenicki |
Posted - 11/01/2011 : 15:35:38
So, I have created a new adapter which converts the AM29F032B to 36 pin DIP, and a 36 pin DIP to 32 pin DIP w/ A19, A20, and A21 headers.
It has no extra parts, no resistors, chips, capacitors, or diodes.
I can write and verify these chips fine with my adapter, but with the MCUMall one, it still fails on verify unless you change the voltage jumper to 3.3v.
This tells me that there is a defect in the design of the ADP-082 adapter. |
| rkrenicki |
Posted - 10/28/2011 : 08:59:51
I agree, this needs to be addressed. |
| stevenc |
Posted - 10/11/2011 : 09:39:41
I wouldnt consider this fixed. Software issue needs to be addressed.
|
| rkrenicki |
Posted - 10/11/2011 : 03:49:12
So, is this considered "fixed", or are we going to continue to look into this issue? |
| rkrenicki |
Posted - 10/06/2011 : 15:46:31
I received my ST M29F032D's today, and they work flawlessly at 5v on Verify. However, this does mean that there is some other difference between the ST and AMD/Spansion part that needs to be addressed. |
| rkrenicki |
Posted - 10/02/2011 : 15:50:45
EZo: I am using the ADP-082. |
| rkrenicki |
Posted - 10/02/2011 : 05:14:25
I also tried 3.6v on verify and it did work (oddly enough).. Perhaps this is a bug in the newer firmware revision? I know I am using GQ-3X version 1.50, instead of the 1.00 that EZo has. |
| Ziggy587 |
Posted - 10/01/2011 : 11:13:57
I still don't understand what the problem is. I've successfully programmed dozens of M29F032D and AM29F032B chips before without any problems. I have never touched any of the jumpers on my adapters (TSOP40A/B ADP-082). Once I updated to the latest software, the problem started. |
| stevenc |
Posted - 09/30/2011 : 19:13:21
Alright, setting the jumper to 3.6v during the verify process works for me. I cant program with it set to 3.6v though, it seems to hang after some time.
I compared what was written to the chip with an hex editor and its the same file.
Extra steps to take, but it works.
Thanks for the help ezo! |
| rkrenicki |
Posted - 09/30/2011 : 18:40:23
"Adapter base TSOP40B has installed jumper Open 3.6V, two others are open. "
So, you had to open VPP1 and VPP2, and put the voltage select on 3.6v? |
| rkrenicki |
Posted - 09/30/2011 : 18:34:36
Well, I ordered 10 ST M29F032D from GQ Electronics, which are on backorder for some reason (although they are in-stock on MCUmall). Once they arrive, I will test however since they are the same chip just by two different manufacturers, I dont see why one would work and the other would not. |
| ZLM |
Posted - 09/30/2011 : 12:14:34
EZoSat: can you try the latest software GQUSBprg 6.13? That should have some improvement. |
| rkrenicki |
Posted - 09/30/2011 : 09:27:02
That is during the write cycle, or the verify cycle? I just ordered some ST M29F032D's from GQ, and I am going to be upset if this programmer does not work with either chip. |
| stevenc |
Posted - 09/30/2011 : 08:10:34
I get 4.45V on pin 12 when writing.
J1-J2 ON
J3 5V
J5 v1.0-v2.0 gives same result |
| rkrenicki |
Posted - 09/30/2011 : 07:09:30
I had tried both 1.0 and 2.0 on v6.13, I only had it on 1.0 under v5.01 and v5.0. I can try 2.0 on v5.0 this afternoon. |
| stevenc |
Posted - 09/29/2011 : 16:14:13
Same thing for me with 5.0 |
| rkrenicki |
Posted - 09/29/2011 : 16:02:39
Same results at -2, except for that it does get to between 6 and 8% checked before failing out. |
| rkrenicki |
Posted - 09/29/2011 : 15:49:00
Actually, with 5.0, Verify gets much further (8% or so) at speed of -2. I am trying an Erase, Blank Check, Write, and Verify at -2 now. |
| rkrenicki |
Posted - 09/29/2011 : 15:06:11
Same error with 5.0 |
| rkrenicki |
Posted - 09/29/2011 : 14:49:46
I found a copy of 5.01 on the internet, and it gives me the same error. I am about to try with the 5.0 that EZo just posted. |
| stevenc |
Posted - 09/29/2011 : 14:11:36
Tried 5.03 and it gave me the same results. |
| rkrenicki |
Posted - 09/29/2011 : 10:54:07
My CD came with 6.13, is there somewhere I can find the download for 5.0? |
| Ziggy587 |
Posted - 09/28/2011 : 11:38:16
I still had the CD I got with my programmer with the 5.0 software on it. I installed the old 5.0 software on my laptop and used it to try and write one of AM29F032B's that failed before, and was able to write it and verify successfully. |
| Ziggy587 |
Posted - 09/28/2011 : 10:45:22
I am having this problem as well. Using the version of the software that came with my programmer when I bought it (5.0) I never got this problem. After I upgraded to the current version software, I get this problem with every AM29F032B I try to write. It will erase and write fine, but then fail to verify. I read the chip back to a .bin and compare it in an hex editor against the original file, it's always 5 bytes that didn't program correctly, and I think they're the same bytes every time.
Also, I noticed on the current version of the software, when I load my file to burn, a window will pop up and ask me what type of file it is (with a list to choose, hex, binary, motorola, etc). The thing is, some of the files I burn have no extension, and some have extensions that are not in the list. I choose .bin anyway, since I believe the files I have are binaries. But the old version of the software didn't have this pop up window. I don't know what the point of it is. |
| rkrenicki |
Posted - 09/27/2011 : 05:58:41
Any other ideas? I would really like to get this to kick over here.. |
| stevenc |
Posted - 09/24/2011 : 14:56:43
Ok tried another thing.
Read the chip twice and saved a different file each time (same setting each times). Compared both files in an hex editor and both files were slightly different.
Tried with the 1k resistor and without, same results. |
| stevenc |
Posted - 09/24/2011 : 13:45:39
Same results.
But with a 1k resistor and without the address wires. The fle thats read from the chip is different than the original file.
And its also different from the file that is read from the chip thats done without the 1k resistor.
|
| rkrenicki |
Posted - 09/24/2011 : 09:52:14
I also had tried that the other day with the same results. I also tried a double-write, with the same results. |
| stevenc |
Posted - 09/24/2011 : 09:46:58
quote:
Originally posted by EZoSat
quote:
I did notice that if I do multiple Verifies.. it fails at a different place each time. This last (known good) chip I burned, failed the first time at 0x0045E8, then 0x00D070 the second time, and finally 0x0053F8 the last time.
Looks chips are programmed OK , SW unstable in verify (read ?)only .
Try lower speed in verify process. Try read (3..5x) and compare result files with external file compare SW (hexedit,..).
Just tried that and it gave me the same results. |
| stevenc |
Posted - 09/23/2011 : 19:18:00
No I didnt hear anything back from ZLM, so I wasnt sure if I should or not.
So it's looking like it might be some software issue then. Which is good since I'm sitting on 36 of those chips and I cant open a dispute on paypal to get a refund anymore. |
| rkrenicki |
Posted - 09/23/2011 : 16:43:12
I did notice that if I do multiple Verifies.. it fails at a different place each time. This last (known good) chip I burned, failed the first time at 0x0045E8, then 0x00D070 the second time, and finally 0x0053F8 the last time. |
| rkrenicki |
Posted - 09/23/2011 : 16:40:18
I located another one of these chips in some old equipment that was about to be discarded. This equipment did work before I got my hands on it, so I know this is a good flash chip.
I IDed, Erased, Blank Check, and Wrote it perfectly. Then the same errors on Verify as the rest. I guess that means that the chips themselves are fine. |
| rkrenicki |
Posted - 09/23/2011 : 07:20:15
Yes, mine are from them as well. It may be worth to consider that they are defective. Did you send any in for testing? |
| stevenc |
Posted - 09/23/2011 : 06:39:58
Yep from beachandantiques on eBay. |
| rkrenicki |
Posted - 09/22/2011 : 16:52:42
I am having the exact same problem with a batch of AM29F032B's that I purchased off of ebay. Out of curiosity Stevenc, were your batch from ebay as well? |
| stevenc |
Posted - 09/14/2011 : 07:18:46
If I were to send a few chips would you be able to test/check them over? |
| ZLM |
Posted - 09/11/2011 : 12:01:03
It could be software problem. But the testing chips are needed in order to find out the problem and fix it.
|
| stevenc |
Posted - 09/08/2011 : 20:20:43
Any ideas?
Programmer/software incompatibility/error?
I doubt all 12 of the chips I tried so far would have been bad. |
| stevenc |
Posted - 09/04/2011 : 09:30:15
On slower speeds I get this:
After erasing it says something along the lines of : This device does not support erasing or doesnt need to be erased.
Even though it just erased what was written onto the chip in previous attempt.
I remove the erase function from auto mode and it passes everything until it gets to verify. Where it fails the same way as before. |
| ZLM |
Posted - 09/04/2011 : 08:37:12
Try to use slower speed and see. |
