Description
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:
- Tools > Board > Arduino/Genuino Uno
- Tools > Programmer > USBasp
- Tools > Burn Bootloader fails with:
C:\Program Files (x86)\arduino-1.6.10\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\arduino-1.6.10\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -cusbasp -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m
avrdude: Version 6.3, compiled on Jun 22 2016 at 16:05:21
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:\Program Files (x86)\arduino-1.6.10\hardware\tools\avr/etc/avrdude.conf"
Using Port : usb
Using Programmer : usbasp
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : usbasp
Description : USBasp, http://www.fischl.de/usbasp/
avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
Error while burning bootloader.
avrdude: error: program enable: target doesn't answer. 0
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
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.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Participants
Activity
bperrybap commentedon Jul 31, 2016
You really need to update the firmware in the USBasp device.
The f/w in your device is a minimum of 7 years out of date.
If you don't update your USBasp device, then depending on your USBasp device you will not be able to burn the fuses or upload any code to a virgin AVR chip.
Even worse, the old code can create false issue due to its bugs so you can can end up chasing false issues that can actually be due to using the old f/w that can sometimes be hidden by various external environmental differences such as versions of avrdude, or host OS, or speed of host.
@PeterVH and I worked on creating an updated version of USBasp that fixes many issues.
I have an updated version of the code here:
https://github.com/bperrybap/usbasp/tree/1.06-alpha
Make sure to use the 1.06-alpha tag version of the code.
It includes many bug fixes and updates
The biggest updates/fixes being:
It comes with tools (cmdline & GUI) for linux and windows to help update the device.
There is an arduino forum thread about USBasp updates here:
http://forum.arduino.cc/index.php?topic=363772.0
per1234 commentedon Jul 31, 2016
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.
bperrybap commentedon Jul 31, 2016
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.
The only real issue left in the 1.06 alpha code is that I added an extra 4k SCK auto clock and the auto code can accidentally pick it from some clocks like for an 8k F_CPU part and not work.
I need to just remove it, do a tiny bit of cleanup and release the code.
The other atomicity stuff is not really something that should be an issue as it is fixing some subtle signal handling during initialization. It is making the code a bit more robust, but the previous less robust code has been "working" for years in the standard USBasp code.
per1234 commentedon Jul 31, 2016
Wonderful, I'll switch to using 1.06 for everything. Thanks so much for your work on the USBasp firmware!
facchinm commentedon Aug 2, 2016
Hi @per1234 , do you confirm that version USBasp with FW 1.06 works with latest avrdude shipped by arduino with all possible Zadig combinations?
The build is configured to link against libusb-1.0.20 with should be the successor of libusb-win32. In fact,
configureconfirms thatI believe that mainline avrdude links against libusb-win32 even if the project is defunct, maybe there are subtle differences between these two projects?
per1234 commentedon Aug 2, 2016
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.
bperrybap commentedon Aug 2, 2016
@per1234
I'm seeing a different issue.
When trying to burn a bootloader using 1.6.10 on linux on a m328 part, it fails when attempting to write fuse bytes.
The fuse byte read doesn't match the byte read. It looks like something is either trying to muck with the unused fuse bits or something is not properly setting the fuse values to be written.
(hopefully it is just that the fuse values in the boards.txt value are incorrect)
Ok. I guess I need to jump into the middle of all this and track this down.
Just doing testing to "see if something works" is nonsense to me.
Testing is not the answer.
What needs to happen is to look at the code and see what it is doing and what has changed and see how that change affects things.
From the issues I'm seeing related to this recently, there are some new issues with fuse writes/reads/verification.
I've seen many issues related to unused fuse bits for quite some time (many years).
The Atmel documents are very clear. Any unused bit should be set to 1 when writing and will read as 1 from the part when reading.
I've seen many crazy attempts to deal with unused fuse bits that are trying to solve a non problem by attempting to ignore/mask/muck with the unused fuse bits. This is solving any potential problems in the wrong place.
The way this should work is:
That way the full 8 bit values of what was written vs what was read can be compared regardless of there being any unused bits in the byte.
Attempting to mask unused bits is the wrong way to go about handling unused bits.
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.
per1234 commentedon Aug 2, 2016
I think you're running into arduino/Arduino#5175. Try changing the
extended_fusesvalues according to arduino/Arduino#5182bperrybap commentedon Aug 2, 2016
@per1234
Yep, an incorrect extended fuse value in boards.txt was it. modifying the efuse allowed it to work.
So with 1.6.10 I can burn a bootloader using USBasp running my 1.0.6-alpha code on a m328p using 32 bit Linux Mint 17.1 LTS.
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.
Normally that error is cause by USBasp saying that it couldn't enter 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.
per1234 commentedon Aug 2, 2016
Yes, same exact output with usbasp-v1.06-alpha-2016-05-18. I sometimes get the
Error while burning bootloader.at the end of the output: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.
bperrybap commentedon Aug 3, 2016
The "Error while burning bootloader." is from the IDE.
What is important is avrdude messages.
What is concerning is the message:
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.
per1234 commentedon Aug 3, 2016
I just reflashed my USBasp to make absolutely sure of the firmware version: fw_update.txt
As you can see in the following logfiles, I only get that message with avrdude 6.3.0-arduino2 and libusb-win32.
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.
bperrybap commentedon Aug 3, 2016
I can't tell you what is causing it but here is why usbasp in avrdude is blowing up.
The usbasp code in avrdude often doesn't check to see if commands to the usbasp device succeed.
In this case the first command to be checked is the USBASP_FUNC_ENABLEPROG and that is causing the failure.
The fist command USBASP_FUNC_GETCAPABILITIES is checked but if it fails then TPI mode is silently disabled if available for the target part.
The other two commands: USBASP_FUNC_SETISPSCK and USBASP_FUNC_CONNECT were sent and but code never bothers to check if the worked.
The commands all actually seem to be working. (the bytes in the buffer seem to indicate this)
However, there is an issue.
If you look closely at the diagnostic output you will notice a line just below each usbasp_transmit(... line that starts with <= followed by a some bytes inside [ ] brackets.
What you will notice is that ones that work have less than 4 bytes on USBASP_FUNC_SETISPSCK, USBASP_FUNC_CONNECT, and USBASP_FUNC_ENABLEPROG but the one that fails always has 4.
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.
The USBASP_FUNC_ENABLEPROG returns a single status byte.
The usbasp code considers the command a failure if the command does not return exactly 1 byte and that byte is no equal to zero.
In the case where it fails libusb returns 4 bytes instead of 1 so the usbasp code in avrdude considers the USBASP_FUNC_ENABLEPROG to have failed.
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 me there is no excuse for that. I only bring that up since perhaps the Arduino 6.3 sources are not the same as the 6.3 pre-built image in the zip image.
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.
per1234 commentedon Aug 3, 2016
@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:
mikson7 commentedon Dec 31, 2016
I have the same issue with my USBasp and I can't bootload my ATMega. :(
per1234 commentedon Dec 31, 2016
@mikson7 did you try installing the libusbK driver to see if that fixes the issue?
ManuTester commentedon Jan 20, 2018
Just a short note:
I have experienced the same problem:
I have libusb-win32 v1.2.2.0 driver installed for USBasp.
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 error looks like this:
avrdude: Warning: cannot query manufacturer for device: No such file or directory
avrdude: Warning: cannot query product for device: No such file or directory
avrdude: error: could not find USB device with vid=0x16c0 pid=0x5dc vendor='www.fischl.de' product='USBasp'
The USBasp has exactly vid=0x16c0 pid=0x5dc.
sleemanj commentedon Jan 20, 2018
@ManuTester
The libusbK driver probably will work, see my guide for install here using the zadig installer.
http://sparks.gogo.co.nz/usbasp_drivers.html
nerdralph commentedon Jun 2, 2018
@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.
shinmai commentedon Jun 4, 2019
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.
pfeerick commentedon Nov 2, 2019
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
avrdude: Warning: cannot open USB device: Function not implementederror that appears on the 'working' avrdude binary... huh?For reference...
Before:
After
Ivoz commentedon Apr 15, 2025
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