avrdude 6.3.0-arduino2 incompatible with USBasp using libusb-win32 driver

[per1234]

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:

1. Tools > Board > Arduino/Genuino Uno
2. Tools > Programmer > USBasp
3. 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.

[bperrybap]

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:

• properly handles ISP SCK, MOSI, & MISO signals
• auto detects a usable SCK frequency
• properly handles large flash used in 1280/1284/2560 chips

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]

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]

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]

Wonderful, I'll switch to using 1.06 for everything. Thanks so much for your work on the USBasp firmware!

[facchinm]

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, configure confirms that

DO HAVE    libelf
DO HAVE    libusb
DO HAVE    libusb_1_0
DO HAVE    libftdi1
DON'T HAVE libftdi
DO HAVE    libhid
DO HAVE    pthread
DISABLED   doc
ENABLED    parport
ENABLED    linuxgpio

I believe that mainline avrdude links against libusb-win32 even if the project is defunct, maybe there are subtle differences between these two projects?

[per1234]

do you confirm that version USBasp with FW 1.06 works with latest avrdude shipped by arduino with all possible Zadig combinations?

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:

driver	6.0.1-arduino5	6.3.0-arduino2
libusb-win32 1.2.6.0	works	doesn't work
libusbK 3.0.7.0	works	works
USB Serial(CDC)	doesn't work	doesn't work
WinUSB 6.1.7600.16385	doesn't work	works

Let me know if there's anything else you want me to test.

[bperrybap]

@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:

• all fuse bytes must be 8 bits and set unused bits to
• avrdude should not muck with the bits in any way.
  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]

When trying to burn a bootloader using 1.6.10 on linux on a m328 part, it fails when attempting to write fuse bytes.

I think you're running into arduino/Arduino#5175. Try changing the extended_fuses values according to arduino/Arduino#5182

[bperrybap]

@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]

Do you get that exact sequence and error with the 1.0.6-alpha code?

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:

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.
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.

Error while burning bootloader.

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]

The "Error while burning bootloader." is from the IDE.
What is important is avrdude messages.
What is concerning is the message:

avrdude: warning: cannot set sck period. please check for usbasp firmware update.

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]

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.

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.

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.

command used for avrdude 6.3:

"C:\Program Files (x86)\arduino-1.6.10\hardware\tools\avr/bin/avrdude" -C"C:\Program Files (x86)\arduino-1.6.10\hardware\tools\avr/etc/avrdude.conf" -v -v -v -v -patmega328p -cusbasp -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m -l avrdudeoutput.txt

• avrdude 6.3.0-arduino2 with libusb-win32 1.2.6.0: avrdude_6.3.0-arduino2_libusb-win32.txt
• avrdude 6.3.0-arduino2 with libusbK 3.0.7.0: avrdude_6.3.0-arduino2_libusbk.txt
• avrdude 6.3 from http://download.savannah.gnu.org/releases/avrdude/avrdude-6.3-mingw32.zip with libusb-win32 1.2.6.0: avrdude_6.3.0_libusb-win32.txt

command used for avrdude 6.0.1-arduino5:

"C:\Program Files (x86)\arduino-1.6.9\hardware\tools\avr/bin/avrdude" -C"C:\Program Files (x86)\arduino-1.6.9\hardware\tools\avr/etc/avrdude.conf" -v -v -v -v -patmega328p -cusbasp -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m -l avrdudeoutput.txt

• avrdude 6.0.1-arduino5 with libusb-win32 1.2.6.0: avrdude_6.1.0-arduino5_libusb-win32.txt
• avrdude 6.0.1-arduino5 with libusbK 3.0.7.0: avrdude_6.1.0-arduino5_libusbk.txt

But it is starting to sound like there are libusb issues on the OS you are using.

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]

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]

@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:

1. Download Zadig from http://zadig.akeo.ie/
2. Plug the USBasp into your computer
3. Start Zadig
4. Options > List all devices
5. Select USBasp from the dropdown menu
6. Select libusb-win32 (v1.2.6.0)
7. Click Install
8. Start Arduino IDE
9. Install Arduino AVR Boards 1.6.12 in Tools > Boards > Boards Manager if you're using a previous version
10. Unplug USBasp
11. Connect the USBasp to your Arduino
12. Plug the USBasp into your computer
13. Tools > Board > select your Arduino
14. Tools > Programmer > USBasp
15. Tools > Burn Bootloader