Closed mcuee closed 8 months ago
As per @avrfreak, the response is different every time. Even when unplugging the USB cable from the port and trying again.
Failed log 1: https://github.com/avrdudes/avrdude/files/13696708/V7.3_log.txt
G:\avrdude7.3>avrdude -C avrdude.conf -vvvv -c snap
_updi -p avr32DD20 -B 4.0 -e -U flash:w:flash.hex:a -U eeprom:w:eep.hex:a
avrdude: Version 7.2-20231215 (c7155f9)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is G:\avrdude7.3\avrdude.conf
Using port : usb
Using programmer : snap_updi
Setting bit clk period: 4.0 us
avrdude: jtag3_open_updi()
avrdude: HV UPDI support: 1
avrdude: usbhid_open(): probing for max packet size
Failed log 2: https://github.com/avrdudes/avrdude/files/13696725/V7.3_log2.txt
G:\avrdude7.3>avrdude -C avrdude.conf -c snap_updi
-vvvv -p avr32DD20 -B 4.0 -e -U flash:w:flash.hex:a -U eeprom:w:eep.hex:a
avrdude: Version 7.2-20231215 (c7155f9)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is G:\avrdude7.3\avrdude.conf
Using port : usb
Using programmer : snap_updi
Setting bit clk period: 4.0 us
avrdude: jtag3_open_updi()
avrdude: HV UPDI support: 1
avrdude: usbhid_open(): probing for max packet size
avrdude: usbhid_open(): setting max_xfer from DAP_Info response to 64
avrdude: found CMSIS-DAP compliant device, using EDBG protocol
avrdude: jtag3_getsync()
avrdude: jtag3_edbg_prepare()
avrdude: jtag3_edbg_prepare(): connection status 0x01
avrdude 7.2 release is okay as per @avrfreak. https://github.com/avrdudes/avrdude/files/13696709/v72_LOG.txt
avrdude: Version 7.2
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is G:\avrdude-v7.2-windows-x86\avrdude.conf
Using Port : usb
Using Programmer : snap_updi
Setting bit clk period : 4.0
avrdude: jtag3_open_updi()
avrdude: HV UPDI support: 1
avrdude: usbhid_open(): probing for max packet size
avrdude: usbhid_open(): setting max_xfer from DAP_Info response to 64
avrdude: found CMSIS-DAP compliant device, using EDBG protocol
avrdude: jtag3_getsync()
avrdude: jtag3_edbg_prepare()
avrdude: jtag3_edbg_prepare(): connection status 0x01
avrdude: sending sign-on command:
avrdude: jtag3_edbg_send(): sending 3 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 0 (command_sequence == 0)
Raw message:
01 80 00
[general] OK
... (skipped) ...
@avrfreak
Please try the following binaries to see if there are any differences in the behavior. The issue seems to be related to HIDAPI.
Latest git main github action binaries. 1) Windows 32bit mingw32 cross-build using Arduino avrdude-packing script, using hidapi 0.12.0 https://github.com/avrdudes/avrdude/actions/runs/7242320665 (download dist.zip and then get the 32bit Windows binary)
2) Windows 64bit mingw64 and msvc64 binaries https://github.com/avrdudes/avrdude/actions/runs/7242320659 avrdude-mingw-x86_64.zip --> avrdude mingw64 binary with MSYS2 bundled hidapi library, using hidapi 0.14.0. avrdude-msvc-x64.zip --> avrdude msvc64 binary with avrdude bundled hidapi library, same as hidapi 0.13.0.
Note: github action mingw64 build uses the following as per the log.
mingw-w64-x86_64-hidapi-0.14.0-2 mingw-w64-x86_64-libelf-0.8.13-7
mingw-w64-x86_64-libftdi-1.5-5 mingw-w64-x86_64-libserialport-0.1.1.r399.6f9b03e-1
mingw-w64-x86_64-libusb-1.0.26-1 mingw-w64-x86_64-libusb-compat-git-r76.b5db9d0-2
mingw-w64-x86_64-ncurses-6.4.20230708-1 mingw-w64-x86_64-readline-8.2.007-1
mingw-w64-x86_64-termcap-1.3.1-7
I tested both versions msvc & mingw on windows 10 with a snap debugger as the programmer. They are both working with older devices but not with the new AVREB. I will post the log files here & the other thread.
I tested both versions msvc & mingw on windows 10 with a snap debugger as the programmer. They are both working with older devices but not with the new AVREB. I will post the log files here & the other thread.
Thanks for the updates.
As per @MCUdude, SNAP does not support AVR EB yet in AVR mode.
@avrfreak
Just want to confirm that the issue is only with AVR EB.
avrdude git main is working with AVR DD, right? Your original report is with AVR32DD20.
V7.3 does not work with the SNAP debugger/programmer regardless of the device that is being programmed. It only works with V7.2.
If they were working earlier today they are not working now. I have been using the snap programmer all day today (and every day) with avrdudeV7.0 without any problems whatsoever. I am not using anything else that may change my programmer/debugger configuration, so there must be a modification in the V7.3 that doesn't work correctly.
I would like to know how avrdude V7.3 was tested? What programmer was used? Will jtag2updi work with V7.3? Thanks
I would like to know how avrdude V7.3 was tested? What programmer was used? Will jtag2updi work with V7.3? Thanks
There is no avrdude 7.3 release yet. jtag2updi should work with avrdude git main (which is close to avrdude 7.3 if no big issues were found).
Please help to provide a clear description of the issue you encountered -- basically avrdude 7.2 works with the devices you tested (please list them) but not avrdude git main.
If they were working earlier today they are not working now.
So avrdude git main was working previously but not any more? Sorry your reports are vague and I do not quite understand what you are trying to say.
@avrfreak
Still thanks a lot for carrying out the tests on git main. If this issue is confirmed to be a regression from avrdude 7.2, it will be a high priority to fix before avrdude 7.3 release.
I will need to set up my SNAP to test with an AVR Dx chip.
Just a first test with a classic ATmega32A first, using SNAP in JTAG mode and there is no issue (same for PICKit 4).
PS> .\avrdude_git -c snap -p m32a -U flash:v:m32a_blink_read.hex:i
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e9502 (probably m32a)
avrdude_git: processing -U flash:v:m32a_blink_read.hex:i
avrdude_git: verifying flash memory against m32a_blink_read.hex
Reading | ################################################## | 100% 0.08 s
avrdude_git: 526 bytes of flash verified
avrdude_git done. Thank you.
Full debug log with -vvvv
.
@mcuee Do we have more intell on this to either confirm this issue or, failing that, close it?
I just tested it again. Not working with a snap debugger. Here is the log file.
here is the exact same setup using avrdude v7.2. It is working. logfile.txt
@avrfreak We have no doubt that you experience this issue. The problem we have is that @mcuee who has access to a lot of platforms has been unable to reproduce the issue, which is kind of important for us to investigate further.
The other peculiarity is that some of your runs appear to have worked earlier on. Begs the question what was the difference in the setup/OS/libraries/machine comms on your side between when those binaries worked on your machine at the time and when they did not work just now. Knowing the answer to that might help us reproduce the issue and investigate further.
I will try it on other computers. I have several. I will let you know. Thank you
It appears there are two drivers for the snap programmer/debugger.
Maybe this is the reason why avrdude does not communicate with the programmer correctly.
I attached some pictures.
If anyone else is using the snap debugger with avrdude can you please let me know what drivers it is using? Thanks
I tried it on another PC. It looks like the driver is different. It appears to be working with an avr16EA28.
@mcuee Do we have more intell on this to either confirm this issue or, failing that, close it?
I can not produce the issue myself.
I can only think this is an issue with the HID interface of the SNAP. It could be an issue with HIDAPI, or a specific issue with @avrfreak's system, or it could be the way how avrdude is using hidapi.
@Youw
The issue is quite strange to me. Just wondering if you have some idea to further debug this issue.
I think something changed in avrdude because V7.2 always works with the snap programmer, no matter what driver version is installed on my computer. It's just this version that does not work with the snap programmer: Version 7.2-20231218 (67792ca)
As long as we don't have a reproducible way to observe the described issue we are a bit stuck. @avrfreak You can help by isolate the conditions when the issue occurs for you and when it does not.
Last time it was reported that Microchip PICKit 2 (USB HID) may have some issues with some Windows applications. But then different host application may work around the issue.
I am not so sure it is a similar issue here or not -- some Windows applications may interfere with Microchip SNAP or PICKit 4 (using USB HID interface for avrdude).
As long as we don't have a reproducible way to observe the described issue we are a bit stuck. @avrfreak You can help by isolate the conditions when the issue occurs for you and when it does not.
Yes I can help. The PC that does not work is a W7 x64 machine. I have tested it on a laptop with W10 it appears to be working.
Again, previous avrdude versions before this are working so something must have changed in avrdude.
The PC that does not work is a W7 x64 machine.
@mcuee Is that something you can confirm?
The PC that does not work is a W7 x64 machine.
@mcuee Is that something you can confirm?
Unfortunately I do not have legacy Windows installations (Windows 7/8/8.1). I only have Windows 10/11. Hopefully someone else with Windows 7 machine can chime in and help. I do not think Windows 7 is the real issue here though as HIDAPI should work fine under Windows 7 (it may even work in older version of Windows as it has not dropped the support of Windows XP yet).
@avrfreak
Still I do not think Windows 7 is the real issue. If possible, please test in another Windows 7 machine.
I tested in another windows 7 machine, still not working, however Avrdude v7.2 is working. Something must have changed in the newer version of avrdude.
ok so you edited my post and changed the title of the thread. The main subject was dealing with the SNAP programmer in avrdude which was working until the newest beta release. The problem is NOT with windows 7, it is with avrdude.
ok so you edited my post and changed the title of the thread. The main subject was dealing with the SNAP programmer in avrdude which was working until the newest beta release. The problem is NOT with windows 7, it is with avrdude.
The problem is avrdude under Windows 7.
But if you also encounter problems under Windows 10 or Windows 11, let me know and I will change the title back.
I edit your post to properly use the code tag (three "`"). But somehow you delete your post. Please help to post again. Thanks.
This is an example.
Anyway, I can post your deleted post back here.
Yes it is correct that AVR EBs are not supported by PICKit 4 and SNAP yet. Please refer to the comment below.
Tested avrdude on a PC with windows 10 using the snap programmer with an AVR16EB32. Not working. Using the logic analyzer, it appears that the SIB is read but then it stops. Here is a verbose log:
https://github.com/avrdudes/avrdude/files/13830505/logfile.txt
Another note, I can't seem to make the code tags work on this forum (when trying to post the log text) It formats only the first portion. Is this a bug or maybe I am doing something wrong? here is how the log appears:
avrdude: Version 7.2-20231218 ([67792ca](https://github.com/avrdudes/avrdude/commit/67792ca8c6da78fd13d6eb82f5e72d8647b0d71a))
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is G:\avrdude\msvc\avrdude.conf
Using port : usb
Using programmer : snap_updi
Setting bit clk period: 4.0 us
avrdude: jtag3_open_updi()
avrdude: HV UPDI support: 1
avrdude: usbhid_open(): probing for max packet size
avrdude: usbhid_open(): setting max_xfer from DAP_Info response to 64
avrdude: found CMSIS-DAP compliant device, using EDBG protocol
avrdude: jtag3_getsync()
avrdude: jtag3_edbg_prepare()
avrdude: jtag3_edbg_prepare(): connection status 0x01
avrdude: sending sign-on command:
avrdude: jtag3_edbg_send(): sending 3 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 0 (command_sequence == 0)
Raw message:
01 80 00
[general] OK
avrdude: input file flash.hex auto detected as Intel Hex
avrdude: input file eep.hex auto detected as Intel Hex
AVR Part : AVR16EB32
Programming modes : UPDI, SPM
Memory Size Pg size Offset
-----------------------------------------
eeprom 512 8 0x1400
flash 16384 64 0x800000
fuses 16 1 0x1050
fuse0/wdtcfg 1 1 0x1050
fuse1/bodcfg 1 1 0x1051
fuse2/osccfg 1 1 0x1052
fuse5/syscfg0 1 1 0x1055
fuse6/syscfg1 1 1 0x1056
fuse7/codesize 1 1 0x1057
fuse8/bootsize 1 1 0x1058
fusea/pdicfg 2 1 0x105a
lock 4 1 0x1040
prodsig/sigrow 128 128 0x1080
signature 3 1 0x1080
tempsense 4 1 0x1084
sernum 16 1 0x1090
bootrow 64 64 0x1100
userrow/usersig 64 64 0x1200
io 4160 1 0
sram 2048 1 0x7800
sib 32 1 0
Variants Package F max T range V range
--------------------------------------------------------------------
AVR16EB32-VQFN/TQFP VQFN32 20 MHz [-40 C, 125 C] [1.8 V, 5.5 V]
Programmer Type : JTAGICE3_UPDI
Description : MPLAB(R) SNAP in UPDI mode
avrdude: jtag3_getparm()
avrdude: sending get parameter (scope 0x01, section 0, parm 0) command:
avrdude: jtag3_edbg_send(): sending 6 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 1 (command_sequence == 1)
Raw message:
01 84 01 01 01 0a f9 00 00
[general] Data returned:
0x01 0x01 0x01 0x0a 0xf9 0x00 0x00
ICE HW version : 1
ICE FW version : 1.10 (rel. 249)
Serial number :
avrdude: jtag3_getparm()
avrdude: sending get parameter (scope 0x01, section 0, parm 1) command:
avrdude: jtag3_edbg_send(): sending 6 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 2 (command_sequence == 2)
Raw message:
01 84 01 01 0a 00
[general] Data returned:
0x01 0x01 0x0a 0x00
avrdude: jtag3_setparm()
avrdude: sending set parameter (scope 0x12, section 0, parm 0) command:
avrdude: jtag3_edbg_send(): sending 7 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 3 (command_sequence == 3)
Raw message:
12 80 00
[AVR] OK
avrdude: jtag3_setparm()
avrdude: sending set parameter (scope 0x12, section 0, parm 1) command:
avrdude: jtag3_edbg_send(): sending 7 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 4 (command_sequence == 4)
Raw message:
12 80 00
[AVR] OK
avrdude: jtag3_setparm()
avrdude: sending set parameter (scope 0x12, section 1, parm 0) command:
avrdude: jtag3_edbg_send(): sending 7 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 5 (command_sequence == 5)
Raw message:
12 80 00
[AVR] OK
avrdude: jtag3_initialize(): trying to set JTAG clock to 250 kHz
avrdude: jtag3_setparm()
avrdude: sending set parameter (scope 0x12, section 1, parm 49) command:
avrdude: jtag3_edbg_send(): sending 8 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 6 (command_sequence == 6)
Raw message:
12 80 00
[AVR] OK
avrdude: jtag3_getparm()
avrdude: sending get parameter (scope 0x01, section 1, parm 0) command:
avrdude: jtag3_edbg_send(): sending 6 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 7 (command_sequence == 7)
Raw message:
01 84 01 b2 13 00
[general] Data returned:
0x01 0xb2 0x13 0x00
Vtarget : 5.04 V
avrdude: jtag3_getparm()
avrdude: sending get parameter (scope 0x12, section 1, parm 0) command:
avrdude: jtag3_edbg_send(): sending 6 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 8 (command_sequence == 8)
Raw message:
12 84 00 08 00
[AVR] Data returned:
0x00 0x08 0x00
avrdude: jtag3_getparm()
avrdude: sending get parameter (scope 0x12, section 0, parm 0) command:
avrdude: jtag3_edbg_send(): sending 6 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 9 (command_sequence == 9)
Raw message:
12 84 00 05 00
[AVR] Data returned:
0x00 0x05 0x00
avrdude: jtag3_getparm()
avrdude: sending get parameter (scope 0x12, section 1, parm 49) command:
avrdude: jtag3_edbg_send(): sending 6 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 10 (command_sequence == 10)
Raw message:
12 84 00 fa 00 00
[AVR] Data returned:
0x00 0xfa 0x00 0x00
PDI/UPDI clk : 250 kHz
UPDI SET:
xd->prog_base_msb=80
xd->prog_base=0 0
xd->flash_page_size_msb=0
xd->flash_page_size=40
xd->eeprom_page_size=8
xd->nvmctrl=0 10
xd->ocd=80 f
xd->address_mode=1
avrdude: jtag3_setparm()
avrdude: sending set parameter (scope 0x12, section 2, parm 0) command:
avrdude: jtag3_edbg_send(): sending 54 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 11 (command_sequence == 11)
Raw message:
12 80 00
[AVR] OK
avrdude: sending AVR sign-on command:
avrdude: jtag3_edbg_send(): sending 4 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 12 (command_sequence == 12)
Raw message:
12 a0 00 33
[AVR] FAILED, reason: 0x33
avrdude: bad response to AVR sign-on command: 0xa0
avrdude: retrying with external reset applied
avrdude: sending AVR sign-on command:
avrdude: jtag3_edbg_send(): sending 4 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 13 (command_sequence == 13)
Raw message:
12 a0 00 33
[AVR] FAILED, reason: 0x33
avrdude: bad response to AVR sign-on command: 0xa0
avrdude: retrying with external reset applied
avrdude main() [main.c:1523] error: initialization failed, rc=-1
- double check the connections and try again
- use -B to set lower the bit clock frequency, e.g. -B 125kHz
- use -F to override this check
avrdude: jtag3_close()
avrdude: sending AVR sign-off command:
avrdude: jtag3_edbg_send(): sending 3 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 14 (command_sequence == 14)
Raw message:
12 80 00
[AVR] OK
avrdude: sending sign-off command:
avrdude: jtag3_edbg_send(): sending 4 bytes
avrdude: jtag3_edbg_recv():
avrdude: jtag3_recv(): Got message seqno 15 (command_sequence == 15)
Raw message:
01 80 00
[general] OK
avrdude: jtag3_edbg_signoff()
avrdude done. Thank you.
@avrfreak
Please help to try the mingw32 Windows 32bit binary from the following github action build under your Windows 7 machines. The binary is inside the file dist.zip
.
https://github.com/avrdudes/avrdude/actions/runs/7397687787
@avrfreak
Please help to try the mingw32 Windows 32bit binary from the following github action build under your Windows 7 machines. The binary is inside the file
dist.zip
. https://github.com/avrdudes/avrdude/actions/runs/7397687787
Code tages are not working for me on this forum! I am using the same hex files for testing as always.
G:\Jan4>avrdude -C avrdude.conf -c snap_
updi -p avr64EA28 -B 4.0 -e -U flash:w:flash.hex:a -U eeprom:w:eep.hex:a
avrdude warning: cannot determine file format for flash.hex, specify explicitly
avrdude warning: cannot determine file format for eep.hex, specify explicitly
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9620 (probably avr64ea28)
avrdude: erasing chip
avrdude: processing -U flash:w:flash.hex:a
avrdude error: cannot determine file format for flash.hex, specify explicitly
avrdude error: read from file flash.hex failed
avrdude done. Thank you.
`
here is the same setup using previous version of avrdude with the same hex files, same programmer, etc..
`
G:\avrdude-v7.2>avrdude -C avrdude.conf -c snap_updi -p
avr64EA28 -B 4.0 -e -U flash:w:flash.hex:a -U eeprom:w:eep.hex:a
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9620 (probably avr64ea28)
avrdude: erasing chip
avrdude: processing -U flash:w:flash.hex:i
avrdude: reading input file flash.hex for flash
with 1024 bytes in 1 section within [0, 0x3ff]
using 8 pages and 0 pad bytes
avrdude: writing 1024 bytes flash ...
Writing | ################################################## | 100% 0.20 s
avrdude: 1024 bytes of flash written
avrdude: verifying flash memory against flash.hex
Reading | ################################################## | 100% 0.09 s
avrdude: 1024 bytes of flash verified
avrdude: processing -U eeprom:w:eep.hex:i
avrdude: reading input file eep.hex for eeprom
with 512 bytes in 1 section within [0, 0x1ff]
using 64 pages and 0 pad bytes
avrdude: writing 512 bytes eeprom ...
Writing | ################################################## | 100% 0.70 s
avrdude: 512 bytes of eeprom written
avrdude: verifying eeprom memory against eep.hex
Reading | ################################################## | 100% 0.21 s
avrdude: 512 bytes of eeprom verified
avrdude done. Thank you.
@avrfreak
The code tag works -- you have to use triple ` and not single `.
I have edited your post to show that it works. You can edit it again to see how I use the code tag.
@avrfreak
Please post the hex files. Thanks.
Your latest issue is totally different from the previous posted error logs.
This time the error is with the hex files (flash.hex and eep.hex) but the communication with the SNAP and the Chip are both working.
Previously the communication with the SNAP seems to work but not the chip as per the log file.
avrdude: Version 7.2-20231218 (67792ca) Copyright the AVRDUDE authors; see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is G:\avrdude7.3_beta\avrdude.conf
Using port : usb
Using programmer : snap_updi
Setting bit clk period: 4.0 us
avrdude: jtag3_open_updi() avrdude: HV UPDI support: 1 avrdude: usbhid_open(): probing for max packet size avrdude: usbhid_open(): setting max_xfer from DAP_Info response to 64 avrdude: found CMSIS-DAP compliant device, using EDBG protocol avrdude: jtag3_getsync()
avrdude: jtag3_edbg_prepare() avrdude: jtag3_edbg_prepare(): connection status 0x01 avrdude: sending sign-on command: avrdude: jtag3_edbg_send(): sending 3 bytes avrdude: Version 7.2-20231218 (67792ca) Copyright the AVRDUDE authors; see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is G:\avrdude7.3_beta\avrdude.conf
Using port : usb
Using programmer : snap_updi
Setting bit clk period: 4.0 us
avrdude: jtag3_open_updi() avrdude: HV UPDI support: 1 avrdude: usbhid_open(): probing for max packet size avrdude: usbhid_open(): setting max_xfer from DAP_Info response to 64 avrdude: found CMSIS-DAP compliant device, using EDBG protocol avrdude: jtag3_getsync()
avrdude: jtag3_edbg_prepare() avrdude: jtag3_edbg_prepare(): connection status 0x01 avrdude: sending sign-on command: avrdude: jtag3_edbg_send(): sending 3 bytes
avrdude warning: cannot determine file format for flash.hex, specify explicitly
Is the problem that when compiled under Windows 7 avrdude can no longer recognise Intel Hex files? OK, this is info we can work with. OK, first of all you could do what avrdude suggests: specify the file type explicitly. Use :i
instead of :a
.
So, perhaps The Windows 7 compiler does not understand the "%2zx"
scanf format (z
means the variable to be set is of type size_t
)? Has been around for a long time.
@avrfreak and @stefanrueger
The situation about Windows binaries is a bit complicated. We have three types of Windows binary from github actions, for latest git main.
1) MSVC build (using VS2022, x86, x64 and arm64 build), without libserialport, using avrdude's own libusb/libftdi, using avrdude's own readline wrapper, using hidapi 0.13.0 release https://github.com/avrdudes/avrdude/blob/main/.github/workflows/build.yml https://github.com/avrdudes/avrdude/wiki/Getting-Nightly-Builds-for-AVRDUDE#windows-static-linking-to-dependancies (latest run for git main)
2) MSYS2 mingw32/64 (x86 and x64 build), with libserialport, with GNU Readline, with libusb-1.0.26 and libusb-compat-0.1, with libftdi1, with hidapi 0.14.0. https://github.com/avrdudes/avrdude/blob/main/.github/workflows/build.yml https://github.com/avrdudes/avrdude/wiki/Getting-Nightly-Builds-for-AVRDUDE#windows-static-linking-to-dependancies (latest run for git main)
3) using Arduino avrdude-packing script (32bit x86 build only), using a Linux container with cross compiler, without libserialport, with libusb-1.0.26 and libusb-compat-0.1.7, libftdi1-1.4, hidapi 0.12.0, GNU Readline 8.0. https://github.com/avrdudes/avrdude/blob/main/.github/workflows/arduino_packing.yml https://github.com/avrdudes/avrdude/wiki/Getting-Nightly-Builds-for-AVRDUDE#linux-macos-and-windows-static-linking-to-dependancies (latets run for git main)
More info about the docker container and cross compiler as well as the libraries used https://github.com/arduino/crossbuild/blob/main/Dockerfile https://github.com/arduino/crossbuild/tree/main/deps
@avrfreak
Please try the other two Windows binaries on your Windows 7 machine as well to see if there are behavior differences. To make it more consistent, please use the 32bit x86 MSVC build and MSYS2 mingw32 build.
https://github.com/avrdudes/avrdude/wiki/Getting-Nightly-Builds-for-AVRDUDE File names: 1) avrdude-msvc-x86.zip 2) avrdude-mingw-i686.zip 3) dist.zip (avrdude_main_Windows_32bit.tar.gz) --> Arduino avrdude-packing binary, you already tried under Windows 7
Then please try all three binaries under your Windows 10 machine as well to see if they all work or not.
And please use the following command line if you encounter issue with :a
.
avrdude -C avrdude.conf -c snap_updi -p avr64EA28 -B 4.0 -e
-U flash:w:flash.hex:i -U eeprom:w:eep.hex:i
situation about Windows
I suspect the observed problem where avrdude fails to recognise the INtel hex file stems from a missing C99 flag (or the compiler not implementing ANSI C standard C99) when compiling for Windows 7.
Test with the following C file
#include <stdio.h>
int main() {
size_t n;
printf("type a number\n");
if(1 == scanf("%zi", &n))
printf("you entered %zu\n", n);
else
printf("cannot process %%zi format\n");
}
Compile above to and test with echo 42 | a.out
.
@avrfreak Thanks for reporting a problem you observed. Pro tips:
-vv
or -vvv
outputIt was the ":a" in the command line. I changed it to ":i" and it works. I have used :a all along with no problems. I just copied the command line (with the ":a") from an avrdude GUI I used. I have been using this for years without problems.
If I get some time I will try the other binaries. Thank you
@avrfreak
Thanks for the update.
So at least the Arduino_packing 32bit Windows binary works under Windows 7 now once you use :i
and not :a
.
Please try the other two binaries as well under Windows 7 when you got the time.
@stefanrueger can probably fix this hex file issue with :a
under Windows 7.
Thanks for reporting a problem you observed. Pro tips:
- Create a separate issue for each problem
Tell us what exactly the problem is and how you came to experience it
- OS
- Programmer
- Part
- How connected/rigged up
- AVRDUDE command line
- Output of the command
- Sometimes it also helps us if you upload a file with the
-vv
or-vvv
output- What you would have expected to happen
I have included this in the FAQ with minor addition. Feel free to update. https://github.com/avrdudes/avrdude/wiki/FAQ#how-to-report-an-issue-to-avrdude-project
It is not clear to me what went wrong. I suspect the format "%zx"
does not work as intended in the function couldbe()
. The z
length modifier was introduced in C99 (ie, made standard in 2000).
@mcuee can you find out using the CI whether this is so? Either compile the following C source and execute the a.out
in the CI or add the body of main()
to AVRDUDE's main()
and execute avrdude
in Windows 7; maybe @avrfreak could help and try this out, too.
#include <stdio.h>
int main() {
size_t n;
printf("%%zi format %s\n", 1 == sscanf("42", "%zi", &n) && n == 42? "OK": "fails");
}
If that turns out to be the problem then there could be several reasons:
"%zx"
format; in this case this might be unique to @avrfreak's systemIt could still be a different reason why @avrfreak observes this behaviour.
@stefanrueger
As mentioned, there are three scenarios for the Windows avrdude binaries -- different compiler toolchain and different libraries used.
1) MSVC toolchain in CI -- pretty up-to-date VS2022 v143 toolchain
Dependancies under my Windows 11 machine.
MINGW64 /c/work/avr/avrdude_test/avrdude_bin/github_bin/avrdude-msvc-x64
$ ldd avrdude.exe
ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff8efaf0000)
KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ff8ef260000)
KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ff8ed1d0000)
apphelp.dll => /c/WINDOWS/SYSTEM32/apphelp.dll (0x7ff8e9df0000)
SETUPAPI.dll => /c/WINDOWS/System32/SETUPAPI.dll (0x7ff8ee030000)
msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ff8edf80000)
WS2_32.dll => /c/WINDOWS/System32/WS2_32.dll (0x7ff8edad0000)
RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ff8ef7e0000)
HID.DLL => /c/WINDOWS/SYSTEM32/HID.DLL (0x7ff8eb630000)
WINMM.dll => /c/WINDOWS/SYSTEM32/WINMM.dll (0x7ff8de3f0000)
WINUSB.DLL => /c/WINDOWS/SYSTEM32/WINUSB.DLL (0x7ff8e46e0000)
ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ff8ed040000)
$ objdump -p ./avrdude.exe | grep 'DLL Name:'
DLL Name: SETUPAPI.dll
DLL Name: HID.DLL
DLL Name: WS2_32.dll
DLL Name: KERNEL32.dll
DLL Name: WINMM.dll
DLL Name: WINUSB.DLL
2) MSYS2 mingw toolchin in CI -- pretty up-to-date MinGW GCC toolchain Dependancies under my Windows 11 machine.
MINGW64 /c/work/avr/avrdude_test/avrdude_bin/github_bin/avrdude-mingw-x86_64
$ ldd avrdude.exe
ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff8efaf0000)
KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ff8ef260000)
KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ff8ed1d0000)
ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7ff8ee4e0000)
msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ff8edf80000)
sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7ff8eded0000)
RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ff8ef7e0000)
SETUPAPI.dll => /c/WINDOWS/System32/SETUPAPI.dll (0x7ff8ee030000)
USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ff8ef0b0000)
win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ff8ed600000)
HID.DLL => /c/WINDOWS/SYSTEM32/HID.DLL (0x7ff8eb630000)
GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ff8ee4b0000)
gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ff8ece60000)
msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ff8ed630000)
ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ff8ed040000)
WS2_32.dll => /c/WINDOWS/System32/WS2_32.dll (0x7ff8edad0000)
cfgmgr32.DLL => /c/WINDOWS/SYSTEM32/cfgmgr32.DLL (0x7ff8ecad0000)
$ objdump -p ./avrdude.exe | grep 'DLL Name:'
DLL Name: ADVAPI32.dll
DLL Name: HID.DLL
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: SETUPAPI.dll
DLL Name: USER32.dll
DLL Name: WS2_32.dll
3) MinGW 32bit toolchain using cross-compile in CI -- this one is using a bit older MinGW GCC version
Unfortunately I do not know how to check the dependancies here for the 32bit binary properly using ldd
.
MINGW64 /c/work/avr/avrdude_test/avrdude_bin/github_bin/dist/avrdude_Windows_32bit/bin
$ ldd avrdude.exe
ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff8efaf0000)
ntdll.dll => /c/Windows/SysWOW64/ntdll.dll (0x77c60000)
wow64.dll => /c/WINDOWS/System32/wow64.dll (0x7ff8ef3e0000)
wow64base.dll => /c/WINDOWS/System32/wow64base.dll (0x7ff8edde0000)
wow64win.dll => /c/WINDOWS/System32/wow64win.dll (0x7ff8ef020000)
wow64con.dll => /c/WINDOWS/System32/wow64con.dll (0x7ff8ef000000)
$ objdump -p avrdude.exe | grep 'DLL Name:'
DLL Name: hid.dll
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: SETUPAPI.dll
DLL Name: USER32.dll
DLL Name: WS2_32.dll
I tend to think all three toolchains will have no issues with C99, but maybe the last one can be a potential issue. Based on the last report, the last one (MinGW cross-compiler) seems to have a problem with the auto-recognition of hex file format.
The C runtime library (msvcrt.dll
) inside Windows 7 can potentially be the problem as well. But if it has a problem, then I tend to think all three binaries would have the same problem. Let's wait for the test results of @avrfreak using the three different binaries.
There are two issues reported by @avrfreak here.
1) avrdude can not communicate with the chip under Windows 7. This one is rather strange. I have no idea how it happens. But if the three binaries perform differently, then the issue could be the hidapi version used.
2) avrdude can not automatically recognize the hex file format with :a
, also under Windows 7. This is also strange but at least @stefanrueger has some ideas why it happens.
OK here are some results of my testing:
I tested avrdude-mingw-i686 under windows 7 x64.
This version does not work with the snap programmer. It does work with a serialupdi cable. The hex files are accepted using ":a".
avrdude -C avrdude.conf -c snap_updi -p avr16EA28 -vvvv -l logfile.txt -e -U flash:w:flash.hex:a -U eeprom:w:eep.hex:a
SNAP_logfile.txt
avrdude -C avrdude.conf -c serialupdi -P COM7 -vvvv -l logfile.txt -b 230400 -p avr16EA28 -e -U flash:w:flash.hex:a -U eeprom:w:eep.hex:a
Serial_UPDI_logfile.txt
Here is the output from testing avrdude-msvc-x86 in windows 7 x64. This one works with my snap programmer. The hex files area accepted using ":a". SNAP_logfile.txt Serialupdi_logfile.txt
Here is the output from dist.zip using both snap programmer and serialupdi. The serial cable is a ch340G cable with the diode and resistor mod. Serialupdi_LOG.txt SNAP_logfile.txt this is what happens when ":a" is used for the hex files in the command line: SNAP_logfile2.txt
All working well!. I will working today. I will be available for more testing the next few days. Thank you
@avrfreak
Thanks a lot for the updates.
Please help to carry out the same tests under Windows 10 to see if the behavior is the same or not.
1) This is the version we recommend to the user under Windows.
MSVC build (using VS2022, x86, x64 and arm64 build), without libserialport, using avrdude's own libusb/libftdi, using avrdude's own readline wrapper, using hidapi 0.13.0 release https://github.com/avrdudes/avrdude/blob/main/.github/workflows/build.yml https://github.com/avrdudes/avrdude/wiki/Getting-Nightly-Builds-for-AVRDUDE#windows-static-linking-to-dependancies (latest run for git main)
Known Issues for this version:
2) This is the second choice for Windows users.
MSYS2 mingw32/64 (x86 and x64 build), with libserialport, with GNU Readline, with libusb-1.0.26 and libusb-compat-0.1, with libftdi1, with hidapi 0.14.0. https://github.com/avrdudes/avrdude/blob/main/.github/workflows/build.yml https://github.com/avrdudes/avrdude/wiki/Getting-Nightly-Builds-for-AVRDUDE#windows-static-linking-to-dependancies (latest run for git main)
Known limitation of this build
-c urclock
in terminal mode)3) This is likely to be used by Arduino distributions under Windows, Linux and macOS.
using Arduino avrdude-packing script (32bit x86 build only), using a Linux container with cross compiler, without libserialport, with libusb-1.0.26 and libusb-compat-0.1.7, libftdi1-1.4, hidapi 0.12.0, GNU Readline 8.0. https://github.com/avrdudes/avrdude/blob/main/.github/workflows/arduino_packing.yml https://github.com/avrdudes/avrdude/wiki/Getting-Nightly-Builds-for-AVRDUDE#linux-macos-and-windows-static-linking-to-dependancies (latets run for git main)
Known limitation of this build
-c urclock
in terminal mode)
From the comments here by @avrfreak
I tested v7.3, it just hangs like avrdude cannot find the com port. (just like in older versions if the programmer was not connected) V7.0 & V7.2 both work well with my programmer.
FYI I use a snap debugger connected to the USB port. The debugger is in avr mode.
I am using :
I have a few AVR16EB32's to test with if anyone has any ideas why it's not working with my programmer.