avrdude git main issue with SNAP and PICKit 4 under Windows 7 -- MinGW build #1594
Comments
|
As per @avrfreak, the response is different every time. Even when unplugging the USB cable from the port and trying again. Failed log 1: Failed log 2: |
|
avrdude 7.2 release is okay as per @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.
Note: github action mingw64 build uses the following as per the log. |
|
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. |
Thanks for the updates. As per @MCUdude, SNAP does not support AVR EB yet in AVR mode. |
|
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. |
mcuee
changed the title
mcuee
added
enhancement
|
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 would like to know how avrdude V7.3 was tested? What programmer was used? Will jtag2updi work with V7.3? |
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.
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. |
mcuee
changed the title
mcuee
added
unconfirmed
|
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). Full debug log with Click for the 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. |
|
@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. |
|
It appears there are two drivers for the snap programmer/debugger. If anyone else is using the snap debugger with avrdude can you please let me know what drivers it is using? |
|
I tried it on another PC. It looks like the driver is different.
|
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. |
|
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: |
|
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). |
|
Here are two Windows 32 bit binaries created by the cross compiler. In my Windows 11 system, both work fine. Please help to carry out the test under your Windows 7 machine to see if the output from |
Since I am now running the container, here are the versions of the cross-compiler used for Linux. Just FYI. They are pretty old but it is probbably because of the desire to be compatible with older version of Linux. 32bit x86 Linux 64bit x86_64 Linux ARM64 Linux ARM32 Linux |
|
Thanks. I think that means the cross-compiler sucks and adding @stefanrueger @umbynos |
Not necessarily; it could well be that the problem is the specific run-time library on @avrfreak's specific Windows 7 system. If that's broken, there is nothing that AVRDUDE can do. Mind you, we do not have a single independent other report of failing |
|
Just want to make sure that MSYS2 mingw and MSVC version do not have the failing Use the following command with Three binaries to use: same as official avrdude git main. |
Thanks a lot for the quick updates. Now it is very clear that both MSVC build and MSYS2 mingw build are okay but the Arduino avrdude-packing build is not okay. |
The Arduino avrdude-packing version has never been in the picture for avrdude project until recently. They are mainly used by the Arduino core users and |
So, we are responsible for fixing it (having made it part of the avrdude project). |
That is only a symptom. We don't know what else goes wrong by not linking to a C99-conforming standard C library. We should fix the root of the problem (not only the symptom) |
Fair enough. Hopefully PR #1608 will fix the issue or at least point out the direction. Right now the following github action will only run after merging of PR #1608. Let's see if it fixes the issue (hex file type auto-recognition) or not. |
Just wondering if you want to keep this issue (avrdude communication problem with AVR chip using SNAP) open or not. It is a bug of avrdude MSYS2 MinGW build under Windows 7, even though it is not a regression. On the other hand, it is probably difficult to debug this issue as it might be related to MSYS2 mingw compiler. |
|
Hello @mcuee
Is there something we can do?
Do you have some suggestion?
That is correct |
|
@umbynos I understand that the Arduino build process either does not compile with at least C99 compatibility or does not link to libraries that are C99-compliant. This has caused problems and may harbour other (so far unknown) problems, because the AVRDUDE project has been relying on availability of C99 (which is 23 years old) Can the Arduino-packaging be made to compile with C99 and link to C99 standard C libraries? |
Probably to upgrade to a new version, like the one from Debian Stable. Or better something similar to Fedora 38/39. |
I'd rather keep #1594 closed. When we receive new issue with a crisp error description that is reproducible by one of the maintainers then we can engage with it again. |
Please help to test the dist version (Arduino avrdude-packing version) of git main with the following two commands under your Windows 7 machine to confirm that Binary to download: download dist.zip and then extract the Windows 32bit binary |
Okay. The only problem is that it is only under Windows 7 and I am not so sure if any of the maintainers have access to Windows 7, which is no longer supported by Microsoft since 14 Jan 2020 (4 years ago). |
|
The first log file proves that @stefanrueger is correct. The compiler or C runtime is the issue for your Windows 7 machine. PR #1608 indeed fixed the symptom. |
|
Hmm, this still proves that @stefanrueger is right with regard to the C library, but then another issue pops up. Can you try with |
|
It's the same thing. -B 4.0 (if I am not mistaken) refers to the SPI SCK rate. This has nothing to do with a UPDI device nor does it have to do with the USB communication between the snap programmer and the PC. |
Thanks a lot for your help. Take your time. For this issue, please help to test the MinGW and MSVC build to see if the compiler plays a part, when you got the time. To make it easier, I have the snapshot here. Please try the following three binaries and the command. https://github.com/mcuee/avrdude/releases/tag/snapshot_2024-01-08 |
@MCUdude
This should be correct. |
|
-B should affect the UPDI clock speed. IIRC you can check the actual UPDI clock speed (in kHz) by using Avrdude in verbose mode (-v). It should change if you change the -B value. |
|
One possibilty to sort out the old Arduino Crossbuild MinGW cross compiler issue, is to give up on the MinGW cross build (we can easily remove it from github action). We anyway recommend people to use the MSVC build first and then MinGW build if the MSVC build does not work. The original intention is anyway to provide static linked version for Linux and macOS users. For the use case of Arduino Core, I think the MSVC build should work pretty well since the limitations do not normally affect Arduino Core users. Or we can use the MinGW build as well. Reference: |
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.
The text was updated successfully, but these errors were encountered: