Read ATF22V10C PES info, show "Unknown GAL"

[Dale-Lien]

Hi ole00,

I am testing an unknown GAL problem, this is my read information, After inserting the afterburner into the USB, read ATF22V10C directly and continuously, All are the same chip. Maybe the i command reset the Type parameter? ps. The chip can read/write correctly on "-t ATF22V10C"

c:\>afterburner_w64 -d COM4 i -t ATF22V10C
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

c:\>afterburner_w64 -d COM4 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
*

c:\>afterburner_w64 -d COM4 i -t ATF22V10C
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

[ole00]

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 your tests. Let us know whether it helped or not.

[rreilink]

Is there a reason why the individual functions of the pc application open and close the serial port? If the serial port is opened only once and closed at the very end of the program, that would fix it in a nice way I suppose. I can give it a try tomorrow.

[Dale-Lien]

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 your tests. Let us know whether it helped or not.

I tested the external power supply, changed the USB port & cable, different GAL, all the same error message. Then I tested version 0.4 of sketch, it worked, it read the correct PES.

c:\>afterburner_w64 -d COM4 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

Now no matter how I replace ATF22V10C or ATF16V8B, PES can be read correctly.

Thanks you, this tool helped me a lot.

[Dale-Lien]

Hi ole00, On V.0.3, after I upload the code, all instructions execute correctly before power off, but after reconnecting after power off, there is a problem.

I took out my logic probe to test the RESET pin, when I read the Info and Reading fuse map before powering off after uploading the code, it only sends out a signal once, and after powering off, plug it into the USB again, when read the Info and Reading fuse map, Four RESET signals were found .

That's why the PES Info can be read normally after re-uploading the code.

So the question should be RESET, but that doesn't explain why using the r command shows the correct type?

Is there a reason why the individual functions of the pc application open and close the serial port? If the serial port is opened only once and closed at the very end of the program, that would fix it in a nice way I suppose. I can give it a try tomorrow.

Hi rreilink, Looking forward to your test.

[ole00]

Is there a reason why the individual functions of the pc application open and close the serial port? If the serial port is opened only once and closed at the very end of the program, that would fix it in a nice way I suppose. I can give it a try tomorrow.

I think it allowed me to 'pause' between commands, open up a serial terminal an query commands. Anyway, I don't like my solution in version 0.4 simply because it hides the issue - why some boards are resetting - they should not be doing that.

[ole00]

I've received genuine arduino uno and tested it on Linux and Windows 7. There were 2 issues I found and fixed. 1) serial data transferred from arduino were often split (compared what was sent from Serial.print()) to smaller chunks which tripped the detection of a serial prompt. 2) Windows 7 could not cope with the baud rate 38400. When some serial data were sent from Window 7 PC the buffer (as read on Arduino) was always prepended by 2 bytes 0xFE or 0xFF. That also caused issues when checking what command was sent from the PC app. The fix was simply to change the baud rate either to 9600 or to 57600. I chose the faster as it seemed reliable. Both changes also work on my arduino clones and are now pushed to github master.

[Dale-Lien]

Hi ole00, My work computer is win7 x64 system. I use mingw64 in msys2 to compile afterburner.c, and it prompts that termios.h is required. Then use gcc in cygwin to compile afterburner.c, the compilation is successful, but failed to open serial device: COM4 is displayed during execution. I tested it with arduino serial monitor and COM4 works fine at 57600.

So there should be something wrong with my compilation,

Can you tell me how to compile it? Or can provide V. 0.4 PC-side program?

best regard.

[ole00]

I use mingw64 in msys2 to compile afterburner.c, and it prompts that termios.h is required.

That's because you did not specify -D_USE_WINAPI. Take a look at the 'compile_win64.sh' script how I cross-compiled the windows version - it will be very similar on native windows gcc environment (msys2). I'll release the binaries soon, just need to test the mac version.

[Dale-Lien]

Thanks, I didn't notice the three .sh files.