ATF22LV10C works, kinda

[NollKollTroll]

I built the programmer and managed to program the ATF22LV10C by selecting ATF22V10C and using -v to override detection. 12V programming voltage needed, 10V did not verify correctly.

[ole00]

Thanks for the info. How do you power your arduino? Via USB cable only, or did you use external power supply? BTW. -v should just enable the verbose mode. Perhaps you meant -t parameter ?

[NollKollTroll]

USB-power only I'm afraid. And yes, -t is the correct parameter. I'll try external power and let you know.

[ole00]

OK. interesting. USB power usually drops the voltage from 5V to ~4.7V depending on the cable quality and its length - in such case I would have expected it to work by using 10V VPP . OTOH if the external power delivers 5V I would have expected the VPP to be set a bit higher (like yours - to 12V) in order to make it work.

So, does you chip identify if you use ./afterburner i -t ATF22V10C and 12V VPP?

[NollKollTroll]

Running VPP at 12V and USB power: afterburner -t ATF22V10C -d /dev/ttyACM0 i PES info: Atmel try VPP=10..14 in 1V steps

[Dale-Lien]

I have tested my ATF22V10C and it can write data using 10V, and erase it.

But there was one chip that couldn't be wiped clean on 10V, so I set it to 11V to erase, no problem. But more than 12V will burn the ATF22V10C.

But using the i parameter to read the information, all ATF22V10C return unknown chip.

My ATF22V10C are all from China.

[rreilink]

I can confirm this. The issue is that the signature is different. See PR https://github.com/ole00/afterburner/pull/15 for a fix.

[ole00]

Thanks for the fix rreilink. It is now merged.

[rreilink]

Reading the info bytes still failed (issue https://github.com/ole00/afterburner/issues/16), fixed by PR https://github.com/ole00/afterburner/pull/17

[rreilink]

Thanks for the fix rreilink. It is now merged.

Thanks for the great application, I was contemplating porting ATFblast myself so you saved me tons of effort :-)

[Dale-Lien]

I read my ATF22V10C and it shows Unknown GAL, But I can use "-t ATF22V10C" to read/write it, So I use the r command to read the PES, It says "N PES 33 43 30 31 56 32 32 46 31 FF*" I looked at the code, PES[3] is 1, so it should show ATF22V10, But it's not.

[ole00]

I read my ATF22V10C and it shows Unknown GAL,

Could you please write the exact command and parameters you use? Then also write the log printed on the console. For example this is what I get if I use:

./afterburner -d /dev/ttyUSB1 i -t ATF22V10C

testing gal 6
PES raw bytes:
33 43 30 31 56 32 32 46 31 FF 
PES info: Atmel ATF22V10C  VPP=10.0 Timing: prog=10 erase=25

If I use read command I get this:

 ./afterburner -d /dev/ttyUSB1 r -t ATF22V10C
testing gal 6
PES raw bytes:
33 43 30 31 56 32 32 46 31 FF 
JEDEC file for ATF22V10C
*QP24*QF5892*QV0*F0*G0*X0*
L0000 11111111111111111111111111111111111111111111*
L0044 11111111111111111111111111111111111111111111*
L0088 11111111111111111111111111111111111111111111*
...
...
L5764 11111111111111111111111111111111111111111111*
L5808 11111111111111111111*
N UES FF FF FF FF FF FF FF FF*
L5828 1111111111111111111111111111111111111111111111111111111111111111*
N PES 33 43 30 31 56 32 32 46 31 FF*
CDD2F
*

[ole00]

But using the i parameter to read the information, all ATF22V10C return unknown chip.

Please not the 'i' command does not do autodetection. Afterburner can not detect the GAL chip that you connected to Arduino. So, you have to always set GAL type by passing the '-t' parameter. The 'i' command is a check (for you) that afterburner is able to communicate with the GAL chip and that the GAL type you selected is correct and the programming voltage is OK.

Edit: I now realised the -t parameter is forced, if it is not set then afterburner should print and error message. That should happen for both 'i' and 'r' commands.

[rreilink]

@Dale-Lien check issue https://github.com/ole00/afterburner/issues/16 , I am experiencing the same. i does not work even with -t ATF22V10C. The pc application sends the GAL type to the Arduino but then the Arduino resets when the serial port is closed and re-opened. It seems you have the same issue. Shall we continue the discussion at https://github.com/ole00/afterburner/issues/16? I have implemented a fix for it but after some comments of @ole00 I noticed my approach is not the best way to fix it.

 % ./afterburner -t ATF22V10C i -d /dev/tty.usbserial-14P52674 -v
Afterburner v.0.3 
opening serial: /dev/tty.usbserial-14P52674
read: 5 ''
opening serial: /dev/tty.usbserial-14P52674
read: 5 ''
opening serial: /dev/tty.usbserial-14P52674
sending 'p' command...
read: 62 'PES info: 3.3V Unknown GAL,  try VPP=10..14 in 1V steps'
PES info: 3.3V Unknown GAL,  try VPP=10..14 in 1V steps
result=0

[Dale-Lien]

I read my ATF22V10C and it shows Unknown GAL,

Could you please write the exact command and parameters you use? Then also write the log printed on the console. For example this is what I get if I use:

On an hour ago, I use "afterburner_w64 -d COM4 i -t ATF22V10C" to read information, and it show(not add #define DEBUG_PES)

PES info: Unknown GAL, try VPP=10..14 in 1V steps

but on now, I add DEBUG_PES & test again, it show:

 testing gal 6
 PES raw bytes:
 33 43 30 31 56 32 32 46 31 FF 
 PES info: Atmel ATF22V10C  VPP=10.0 Timing: prog=10 erase=25

Now regardless of whether DEBUG_PES is added or not, it always show Right type. I don't know why, maybe I can try again tomorrow

[Dale-Lien]

Please not the 'i' command does not do autodetection. Afterburner can not detect the GAL chip that you connected to Arduino. So, you have to always set GAL type by passing the '-t' parameter. The 'i' command is a check (for you) that afterburner is able to communicate with the GAL chip and that the GAL type you selected is correct and the programming voltage is OK.

Yes, I always use i with "-t ATF22V10C" to read my GAL. I am use Win7 x64.

[ole00]

Ok. I can see 2 issues here. Dale-Lien: I think your programming voltage is somehow unstable. That would explain why it sometimes works and sometimes it does not work. Try to increase or decrease the programming voltage a tiny bit (let say 0.1V or 0.2V).

rreilink : I think what you wrote is critical: " the Arduino resets when the serial port is closed and re-opened". In that case the gal type is lost. My Arduino does not reset when the serial port is closed.It looks like you use Mac OS, maybe it is something OS related or the way how the serial port is opened (maybe some extra flag is needed for BSD compared to Linux when setting the serial port configuration).

[ole00]

rrelink: I think here is the clue: https://arduino.stackexchange.com/questions/439/why-does-starting-the-serial-monitor-restart-the-sketch .. from the answer...: "Setting the flow control to none will allow you to connect/disconnect from the serial without resetting your board."

Edit: try to add the following line to serial_port.h, function serialDeviceOpen() - use the one for Unix systems on the bottom of the file. And add this line:

        serial.c_cflag |= CREAD | CLOCAL;
        serial.c_flags &= ~CRTSCTS; // <<<< === this is the new line

Edit2: actually, that probably will not help because the CRTSCTS flag was already unset... hmm..

[Dale-Lien]

Dale-Lien: I think your programming voltage is somehow unstable. That would explain why it sometimes works and sometimes it does not work. Try to increase or decrease the programming voltage a tiny bit (let say 0.1V or 0.2V).

I tried changing the VPP from 10.0V to 11.0V by 0.2V each step and it still shows as Unknown GAL.

I found that when I plug the Afterburner into the USB for the first time, It always read Unknown GAL.

testing gal 4
PES raw bytes:
FF FF 0F 00 00 00 00 00 00 00 
PES info: 3.3V Unknown GAL,  try VPP=10..14 in 1V steps

But when I re-upload the Arduino code, it can show the correct GAL type whether I have pressed reset or not.

testing gal 6
PES raw bytes:
33 43 30 31 56 32 32 46 31 FF 
PES info: Atmel ATF22V10C  VPP=10.0 Timing: prog=10 erase=25

In the last post, I wanted to show PES raw bytes, so I have modified the sketch, then it show correct type.

[Dale-Lien]

@Dale-Lien check issue #16 , I am experiencing the same. i does not work even with -t ATF22V10C. The pc application sends the GAL type to the Arduino but then the Arduino resets when the serial port is closed and re-opened. It seems you have the same issue.

Thank you for your reply, my test result is different from yours, please see issue #18.

After the PC-side program executes operationSetGalType, close the serial port, then open the serial port, send operationReadFuses, and close the serial port again. In this section, the data read is correct. However, after the calculator is executed, Galtype closes the serial port, and then opens the serial port. The data error after readInfo is read by the send operation, and the Gal parameter is reset to 4.

[ole00]

The first output shows "testing gal 4" the second one shows "testing gal 6". So it looks like it might be the same error rrelink identified - the Arduino resets in between reads. Yesterday I tried my 2 Arduinos, none of them resets in between reads. Both are clones, not a genuine one. I ordered a genuine Arduino Uno Rev 3 yesterday, I'm curious to see whether I could replicate the issue on the genuine one and whether it is caused by the hardware, or software.

Here are my clones - very cheap from ebay. Served me well several years.

[Dale-Lien]

My Arduino is clone too, Same as the picture on the right. Please see issue #18, I continuously test reading data, if it is a reset problem, why is the GAL type wrong the first time, right the second time, and wrong the third time? So I think it may be caused by other problems.

[ole00]

why is the GAL type wrong the first time, right the second time, and wrong the third time?

I can only speculate, possible reasons or combinations. The issue seems to be intermittent (sometimes it works, sometimes not) in your case, therefore:

• power might not be sufficient, the board browns-out and resets. Try to use shorter and thicker usb cable, or power Arduino via dedicate 9-12V power supply.
• soldering issue - sometimes unburned flux can create capacitance on the joint and causing problems. Fix: touch the solder joints with hot iron to re-melt them. If you hear sizzling noise - that might be it.
• some software issue
• the GAL IC might be malfunctioning or is damaged and possibly draws to much current causing the board to reset.

Anyway, I've made a modification into the .ino sketch that should remember the gal type between resets. I tested that feature by resetting the board during data commands (to simulate your conditions) and it seems to work better now. Please pull the git repository, upload the sketch and retry. Let us know whether it helped or not.

[Dale-Lien]

Please pull the git repository, upload the sketch and retry. Let us know whether it helped or not.

Thanks, the V. 0.4 works fine.