-
-
Notifications
You must be signed in to change notification settings - Fork 23
avrdude 6.3.0-arduino2 incompatible with USBasp using libusb-win32 driver #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
You really need to update the firmware in the USBasp device. @PeterVH and I worked on creating an updated version of USBasp that fixes many issues. It includes many bug fixes and updates
It comes with tools (cmdline & GUI) for linux and windows to help update the device. |
I tried your usbasp-v1.06-alpha-2016-05-18 and still had this issue. I've been using PeterVH's v1.05 firmware in my everyday use USBasp from the moment it was released. I do have another USBasp with your usbasp-v1.06-alpha-2016-05-18 loaded on it but from reading the pull request it sounded like there were still some issues so I haven't been using it very much but so far haven't encountered any issues. I'm looking forward to the 1.06 release. I also tried usbasp-v1.04-2011-05-28, usbasp-lc-technology-2015-12-29, and the Baite firmware, none of them had any effect on this issue. |
By using the later USBasp code (peter's 1.05 or my 1.06 alpha), at least you know that there are not any USBasp clocking issues creating subtle issues. |
Wonderful, I'll switch to using 1.06 for everything. Thanks so much for your work on the USBasp firmware! |
Hi @per1234 , do you confirm that version USBasp with FW 1.06 works with latest avrdude shipped by arduino with all possible Zadig combinations?
I believe that mainline avrdude links against libusb-win32 even if the project is defunct, maybe there are subtle differences between these two projects? |
No, this issue occurs for me with any firmware version I tried (usbasp-v1.06-alpha-2016-05-18, Peter VH's 1.05, Fischl's 1.04, LC TECHNOLOGIES stock FW, and the stock FW on the "Baite" brand USBasp clone). I didn't test with any Fischl firmware previous to 1.04 but can easily do so if you want me to. I tested on two different computers (Windows 7 64 bit and 32 bit), 5 different USBasp clones, and 3 different USBasp clone models, all with the same results. Here are my results of performing a "Burn Bootloader" operation with USBasp running usbasp-v1.06-alpha-2016-05-18 FW using each driver option in Zadig:
Let me know if there's anything else you want me to test. |
@per1234 Ok. I guess I need to jump into the middle of all this and track this down. From the issues I'm seeing related to this recently, there are some new issues with fuse writes/reads/verification.
If unused bits are not messed with, then all that should be required is that entities that use avrdude need to ensure that they set the unused fuse bits in the byte to 1. That way all 8 bits of the fuse byte can be written, read and compared without issues. I'll go off and look at the avrdude code, the atmel specs, and the fuse byte values used by the IDE when buring a bootloader and see what is going on. I'm really hoping I'm not going to find any goofy code in avrdude that is attempting to muck with unused fuse bits to try to make things "easier" or worse to fix things due to bugs in the chips when reading the fuse bytes. |
I think you're running into arduino/Arduino#5175. Try changing the |
@per1234 I'm still going to go back and look at avrdude and see how it is handling the unused bits. The issue you reported in the first post seems really odd. It appears to connect to the USBasp device and talk enough to realize that it can't set the SCK clock, which means that libusb is working, but then it gets an error when telling the USBasp device to connect to the AVR target to get into ISP programming mode. Do you get that exact sequence and error with the 1.0.6-alpha code? I'll need to go look at the avrdude code to see if a USB issue/error (like a timeout) can cause that avrdude message. |
Yes, same exact output with usbasp-v1.06-alpha-2016-05-18. I sometimes get the
but this isn't associated with any particular firmware, sometimes it's one way, sometimes the other. That's the only difference I've found. |
The "Error while burning bootloader." is from the IDE.
As you should not get that message if you are running 1.0.6-alpha firmware since that f/w supports setting the sck period. If you are running 1.0.6-alpha code then there must be some sort of USB communication issue, likely something in libusb. I went and looked at the avrdude code and nothing has been changed in the USBasp code for 20 months; however, the USBasp avrdude code doesn't really print anything by default when there are USB errors, so there may some USB error conditions that might be masked even when using the IDE's "verbose" mode. One thing that would help is if you could run the avrdude command with a higher level of diagnostic messages. This will show everything including any USB errors. To do that, copy the command from the IDE and run it but add 4 more -v options: -v -v -v -v as each one bumps the diagnostic output level. That will show much more information. But it is starting to sound like there are libusb issues on the OS you are using. |
I just reflashed my USBasp to make absolutely sure of the firmware version: fw_update.txt
command used for avrdude 6.3:
command used for avrdude 6.0.1-arduino5:
The issue only occurs with Arduino's build of avrdude 6.3. As you can see from the logfile, the stock avrdude 6.3 works with libusb-win32, including setting the sck period. |
I can't tell you what is causing it but here is why usbasp in avrdude is blowing up. The commands all actually seem to be working. (the bytes in the buffer seem to indicate this) The code tells libusb to send the command over the USB and also says it can accommodate up to a 4 byte response. Different usbasp commands have different response lengths and libusb is supposed to return the actual number of bytes returned. So I can't tell you where or why it is happening, I can only tell you what is happening and why it is failing. Another thing to keep in mind is that I've seen avrdude be very sloppy with its revisions. There were actually several 5.11 versions that were released and they were not all the same code! To really test and verify it, you should build it from source and then if it fails, use gdb so you can source level debuging and set breakpoints or watch points to see what is screwing up the return byte count. |
@bperrybap thanks for looking into this. I'm not sure when I'll have time to look into building avrdude from source, etc. I know that's lame but the issues caused by the last Arduino release have been eating up all the time I can contribute to Arduino and much more. I'm obligated to put priority on getting all the 3rd party boards projects I'm involved with fixed ASAP. I hope the information I provided and the work you've done will help others. I'm happy to provide any more information requested. If anyone reading this has Windows and a USBasp it would be great if you could see if you can reproduce this issue to make sure it isn't something specific to my computers:
|
I have the same issue with my USBasp and I can't bootload my ATMega. :( |
@mikson7 did you try installing the libusbK driver to see if that fixes the issue? |
Just a short note: I have experienced the same problem: Stock avrdude 6.3 downloaded here: http://download.savannah.gnu.org/releases/avrdude/avrdude-6.3-mingw32.zip works absolutely fine, avrdude 6.3.0-arduino2 does not even recognize the USBasp. The USBasp has exactly vid=0x16c0 pid=0x5dc. |
The libusbK driver probably will work, see my guide for install here using the zadig installer. |
@sleemanj libusbK did the trick for me on Win 7E/64. And my avrdude 6.1/mingW build continues to work fine as it did before. I'm using a LCSoft model with the 2011-05-28 firmware. |
2019 update: Thank dog I found this issue half-accidentally, after recompiling the firmware and re-flashing my USBasp countless times, and still getting the "Can not Set sck period . usbasp please check for firmware update ." warning from avrdude and being unable to even read fuses with it, I was ready to gut and bin the programmer, But sure enough, substituting libusbK for libusb-win32 and the programmer works flawlessly without errors. |
Just been butting heads with this same issue.. and changing the driver to libusbK fixed it for me also (on Windows 10 1903). What was even stranger is the avrdude6.3 shipped with avrdudess worked just fine if I swapped executables. And even more amusing is the For reference... Before:
After
|
This still failed for me using a USBAsp. Old avrdude 6.3 in arduino gave out
If I replace it with modern avrdude 8.0 and its associated conf file, it works fine
Using usbasp firmware 1.08 |
Using Arduino IDE 1.6.10/Arduino AVR Boards 1.6.12 with Windows 7 64 bit and 32 bit
With libusb-win32 v1.2.6.0 driver installed for USBasp:
If I replace C:\Program Files (x86)\arduino-1.6.10\hardware\tools\avr\bin\avrdude.exe with the stock AVRDUDE 6.3 from http://download.savannah.gnu.org/releases/avrdude/avrdude-6.3-mingw32.zip it works as expected(I encounter arduino/Arduino#5175). It also works with USBasp/libusb-win32 v1.2.4.0, I didn't try it with libusb-win32 v1.2.2.0. This indicates to me that there is a way to make AVRDUDE 6.3 compatible with USBasp/libusb-win32. Since this is a very commonly used programmer I think it would be worth trying to make the AVRDUDE included with Arduino compatible with as many drivers as possible. I've already seen two other users report similar issues on the Arduino forum.
If I change the USBasp driver to libusbK v3.0.7.0 it works as expected.
Using avrdude 6.3.0-arduino2 with USBasp/libusb-win32 v1.2.4.0, or v1.2.2.0 also doesn't work but with a different error output(I can post it if necessary).
Using avrdude 6.0.1-arduino5 with USBasp/libusb-win32 v1.2.6.0, v1.2.4.0, or v1.2.2.0 works correctly.
Using avrdude 6.3.0-arduino2 with USBtinyISP/libusb-win32 v1.2.6.0 works as expected.
EDIT: I installed the drivers using Zadig.
The text was updated successfully, but these errors were encountered: