Greetings,
I cant seem to upload the bootloader to a new chip using the Arduino IDE and AVRISPmkII. However i can load the blink program directly into the arduino(328PU), i only get these errors using the "burn bootloader"
Arduino: 1.6.5 (Windows 8.1 (windows 10)), Board: "Arduino Uno"
avrdude: usbdev_open(): did not find any USB device "usb"
Error while burning bootloader.
This is on an arduino UNO rev 3 board.
-lasse
Sounds like you are missing a step, like Tools->Programmer->AVRISP mkII
Greetings,
Thanks for your reply, i would love it to be that simple, but i have been using the AVRISPmkII as the programmer. The serial menu is just open to see what serial ports i have.
I just tried from a windows 7 machine, and i get the same error.
/lasse
I would turn on "verbose output during upload" (see: Prefereces...) to see what avrdude is being told that when the error occurs.
Here is the verbose output, it does make me a little bit suspicious that it says its using the cstk500v2, is that the avrisp?
This is trying to load the bootloader, below this is where i load a blink program and that works
Arduino: 1.6.5 (Windows 8.1), Board: "Arduino Uno"
C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -cstk500v2 -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m
avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"
Using Port : usb
Using Programmer : stk500v2
avrdude: usbdev_open(): Found AVRISP mkII, serno: 0000B0026998
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 : STK500V2
Description : Atmel STK500 Version 2.x firmware
Programmer Model: AVRISP mkII
Hardware Version: 1
Firmware Version Master : 1.23
Vtarget : 3.2 V
SCK period : 4.00 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: erasing chip
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3F:
avrdude: load data lock data from input file 0x3F:
avrdude: input file 0x3F contains 1 bytes
avrdude: reading on-chip lock data:
Reading | ################################################## | 100% -0.00s
avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0x05"
avrdude: writing efuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x05:
avrdude: load data efuse data from input file 0x05:
avrdude: input file 0x05 contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100% -0.00s
avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0xDE"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% -0.00s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDE:
avrdude: load data hfuse data from input file 0xDE:
avrdude: input file 0xDE contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFF:
avrdude: load data lfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude done. Thank you.
C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -cstk500v2 -Pusb -Uflash:w:C:\Program Files (x86)\Arduino\hardware\arduino\avr/bootloaders/optiboot/optiboot_atmega328.hex:i -Ulock:w:0x0F:m
avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"
Using Port : usb
Using Programmer : stk500v2
avrdude: usbdev_open(): did not find any USB device "usb"
Error while burning bootloader.
Log from loading the blink program below
avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"
Using Port : usb
Using Programmer : stk500v2
avrdude: usbdev_open(): Found AVRISP mkII, serno: 0000B0026998
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 : STK500V2
Description : Atmel STK500 Version 2.x firmware
Programmer Model: AVRISP mkII
Hardware Version: 1
Firmware Version Master : 1.23
Vtarget : 3.2 V
SCK period : 4.00 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "C:\Users\spillER\AppData\Local\Temp\build237079435160733442.tmp/Blink.cpp.hex"
avrdude: writing flash (1138 bytes):
Writing | ################################################## | 100% 0.21s
avrdude: 1138 bytes of flash written
avrdude: verifying flash memory against C:\Users\spillER\AppData\Local\Temp\build237079435160733442.tmp/Blink.cpp.hex:
avrdude: load data flash data from input file C:\Users\spillER\AppData\Local\Temp\build237079435160733442.tmp/Blink.cpp.hex:
avrdude: input file C:\Users\spillER\AppData\Local\Temp\build237079435160733442.tmp/Blink.cpp.hex contains 1138 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.19s
avrdude: verifying ...
avrdude: 1138 bytes of flash verified
avrdude done. Thank you.
That is interesting, it seems the programmer is having a problem when avrdude is called 2 times in a row. The bootloader process calls avrdude twice, once to unlock and set fuses, and the second pass to write the bootloader and lock the bootloader. I wonder if your computers are not making the USB device available again immediately, or if the device itself takes some time to recover.
I suggest go ahead run the second step from the command line. The program path to avrdude and the config file and hex file arguments have embedded spaces, so you may need to put them in quotes:
"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude" -C"C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -v -patmega328p -cstk500v2 -Pusb -Uflash:w:"C:\Program Files (x86)\Arduino\hardware\arduino\avr/bootloaders/optiboot/optiboot_atmega328.hex":i -Ulock:w:0x0F:m
Brilliant dmjlambert,
the commandline worked, im not sure if i needed to run the command several times, but i did and it worked.
Thanks a bunch 
/lasse
Here's the GitHub issue for this: Arduino IDE sending avrdude commands to avrisp2 too fast · Issue #2986 · arduino/Arduino · GitHub bperrybap claims to have solved the issue but nothing ever came of it. It's frustrating to me that my $3 USBasp works fine but I can't burn a bootloader with my $40 Atmel AVRISP MKII using the current IDE even though it works fine with Arduino 1.0.6.
That GitHub issue thread is a crazy finger-pointing fest. The simple fix of adding a 3 second pause between avrdude commands in the IDE would solve it for everybody. There would not be a dependency on an avrdude fix, and would not make it necessary to combine the 2 step burn bootloader process into 1 step. I kind of like the 2 step avrdude process.
Just for kicks I edited
"C:\Program Files\Arduino\hardware\arduino\avr\platform.txt"
to change these 2 sections:
tools.avrdude.erase.params.verbose=-v
tools.avrdude.erase.params.quiet=-q -q
tools.avrdude.erase.pattern=""
tools.avrdude.bootloader.params.verbose=-v
tools.avrdude.bootloader.params.quiet=-q -q
tools.avrdude.bootloader.pattern="{cmd.path}" "-C{config.path}" {bootloader.verbose} -p{build.mcu} -c{protocol} {program.extra_params} -e -Ulock:w:{bootloader.unlock_bits}:m -Uefuse:w:{bootloader.extended_fuses}:m -Uhfuse:w:{bootloader.high_fuses}:m -Ulfuse:w:{bootloader.low_fuses}:m "-Uflash:w:{runtime.platform.path}/bootloaders/{bootloader.file}:i" -Ulock:w:{bootloader.lock_bits}:m
This combined the burn all into one avrdude call.
I don't see any detrimental effects right off, we would need good testing to make sure it doesn't mess up other things....
dmjlambert:
C:\Program Files\Arduino\hardware\arduino\avr\platform.txt
I had to make the change to
C:\Users\per\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.6.8\platform.txt instead.
dmjlambert:
we would need good testing to make sure it doesn't mess up other things....
I just tried it out with Atmel AVRISP MKII, USBasp, Arduino as ISP, and USBTinyISP and all work fine. @dmjlambert if you have any other tests you would like me to try I'd be happy to do so and will report back if I run into any problems in ordinary use. Great work on this fix, thanks!
dmjlambert:
The simple fix of adding a 3 second pause between avrdude commands in the IDE would solve it for everybody
The downside to that is I don't think everyone is having this problem(maybe Windows related?) with the MKII and if I understand correctly that would also add the pause to other programmers that are already working so some people might be unhappy to have the burn process slowed down. What disadvantages do you see with just using your current platform.txt fix instead of the delay?
Well my fix is a band-aid. I don't know what a proper set of tests would be, but I suggest use it for a while and maintain awareness that you have a weird platform.txt file in case any issues happen that you can't figure out.
I think we can slow down the whole world of Arduino by 3 seconds for everybody! Maybe people will take another sip of tea and relax. Oh, no! I probably just made thousands of enemies...
I came up with an alternative "band-aid fixworkaround" I thought I'd share in case it might be useful to anyone else. I added a new option in the Tools>Programmers menu that can be used to successfully burn bootloader using AVRISP mkII for people having this issue. It is documented here:GitHub - per1234/Arduino-AVRISPmkII-fix: An ugly workaround for AVRISP mkII not working with Arduino IDE 1.6.x and can be installed using this Boards Manager URL:
https://per1234.github.io/Arduino-AVRISPmkII-fix/package_per1234_Arduino-AVRISPmkII-fix_index.json
I changed this line in programmers.txt:
avrispmkii.program.extra_params=-Pusb
to
avrispmkii.program.extra_params=-Pusb "-Uflash:w:{runtime.platform.path}/bootloaders/{bootloader.file}:i" -Ulock:w:{bootloader.lock_bits}:m
So this causes both avrdude commands to be ran in the "erase" step of Burn Bootloader and so even though the "bootloader" step fails as usual it has already successfully burned the bootloader. So not a very good solutionworkaround but it does have a few advantages(and disadvantages) compared to dmjlambert's fix:
Pros
Cons
That is interesting, good job!
pert:
Here's the GitHub issue for this: Arduino IDE sending avrdude commands to avrisp2 too fast · Issue #2986 · arduino/Arduino · GitHub bperrybap claims to have solved the issue but nothing ever came of it. It's frustrating to me that my $3 USBasp works fine but I can't burn a bootloader with my $40 Atmel AVRISP MKII using the current IDE even though it works fine with Arduino 1.0.6.
More than just a claim. I have fixed it and also proposed an alternate way to address the issue. As I've explained and documented many times over the years, the issue really isn't that complicated.
avrdude resets the USB when it exits. This forces all the USB devices to re-enumerate. Since avrdude doesn't wait for any enumerations when it starts, it will not see any devices that have not completed their enumeration.
This is an issue created by avrdude that should be fixed in avrdude.
The issue can be properly fixed in avrdude with a 6 line patch or the IDE can work around it by doing everything in a single command to avoid the avrdude issue.
dmjlambert:
That GitHub issue thread is a crazy finger-pointing fest. The simple fix of adding a 3 second pause between avrdude commands in the IDE would solve it for everybody. There would not be a dependency on an avrdude fix, and would not make it necessary to combine the 2 step burn bootloader process into 1 step. I kind of like the 2 step avrdude process.
It really isn't a finger-pointing fest. I've explained the issue over and over again and the issue was that those who had the power to fixed it simply wouldn't fix it. It could be addressed in the IDE or avrdude and neither party want to make any changes.
Joerg didn't like fixing it in avrdude because it broke the way he used avrdude. He used an internal error capability/behavior to list his devices on the USB. This is not a documented feature but he liked it. Fixing avrdude would cause his use case to add 3 seconds for every device he was looking for on the USB that wasn't present. He didn't like this. So the bug has been allowed to fester for years.
I do think it is ironic and funny that it tends to only affect official Atmel products.
Things like Atmel studio don't see the issue because it doens't do back to back avrdude commands to the issue is avoided.
The IDE never got fixed because I don't think people were taking the time to read and understand my explanations and then were scared to make any changes to the IDE.
The IDE could do a blind delay but that is a very ugly hack.
Actually the IDE is already doing a blind delay of 1 second. The issue is that the Atmel products are not fast enough with enumeration so the 1 second is not long enough for them.
The problem is how long is long enough? The amount of needed delay somewhat depends on the speed of the host PC and what all is connected that particular USB. Remember there can be internal USB hubs so there could be multiple devices on the same USB even though they are using separate connectors on the host PC and not using an external USB hub.
Note: I also proposed a quick and dirty hack of bumping the blind delay in the IDE to 3 to 4 seconds many years ago. That was flatly rejected by the Arduino team as being unacceptable.
(The arduino team was much less willing to take fixes from the Arduino community back then)
A better work around for the avrdude bug is that the IDE could be fixed to do everything in a single avrdude command rather than two. There is no need to do it in two steps vs 1 and if you do it in 1 then you avoid Joerg's avrdude USB bug and don't need to do any blind delays.
I also proposed that solution many years ago and it has sat as an open issue until recently.
This same issue existed in the makefile for optiboot for years. Westfw eventually recently updated it to do all avrdude operations in a single avrdude command vs multiple commands.
Even he was afraid to change his makefiles for fear of breaking something. The patch to fix the makefile was not implemented for years.
A few months ago I talked with Christian and gave him the 6 line avrdude patch to fix the problem. He took the patch and I think it will soon be part of the avrdude that ships with the IDE. The IDE already ships with a modified avrdude since the arduino team have been unable to get other needed patches/fixes into avrdude as well. I haven't followed up on it but Christian has been very good about getting bug fixes and patches into the IDE for release.
I suspect that this long existing issue will soon be over if it hasn't already been fixed in the latest IDE.
--- bill
bperrybap:
More than just a claim. I have fixed it and also proposed an alternate way to address the issue.
Thanks again for your efforts towards a real solution for this problem.
bperrybap:
I suspect that this long existing issue will soon be over if it hasn't already been fixed in the latest IDE.
The issue still exists using the latest hourly build and there have been no related commits to the Arduino toolchain-avr repository.
I didn't submit a pull request for the patch since Christian and I were discussing about the merits.
He said that given how simple it was he'd take care of it.
I think I'll ping Christian and see what happened.
--- bill
A blind delay of a few seconds is not really an ugly hack, it is a beautiful fix and is completely acceptable for interfacing with a tool which may need a few seconds to connect/recover a USB device. There is also nothing wrong with doing multiple calls to avrdude, that was a great idea from the beginning. I think a 5 second blind delay for safe measure would be great. Heck, make it 10 seconds. It isn't like burning a bootloader is something normally done multiple times all the live long day.
dmjlambert:
A blind delay of a few seconds is not really an ugly hack, it is a beautiful fix and is completely acceptable for interfacing with a tool which may need a few seconds to connect/recover a USB device. There is also nothing wrong with doing multiple calls to avrdude, that was a great idea from the beginning. I think a 5 second blind delay for safe measure would be great. Heck, make it 10 seconds. It isn't like burning a bootloader is something normally done multiple times all the live long day.
I guess beauty/ugly is in the eye of the beholder.
My view is that it is an ugly hack since it doesn't really fix anything. It is a hack attempt to work around the problem.
In order to be reliable the blind delay must be longer than the worst case needed.
It isn't clear how much that is. While it is just under 3 seconds on 2Ghz machines with no other devices on the USB, it isn't clear how to ever know what the worst case scenario is.
Also, USB ISP programming devices that don't need the delay are also penalized when using a blind delay.
This is the reason the Arduino team gave for rejecting increased delay years ago.
I can't say that I really disagree with them.
While there is nothing wrong with doing multiple executions of avrdude, doing so will trigger an issue within avrdude when you do them back to back unless you patch the avrdude code.
I guess my philosophy is that if you are going to make a change to code to fix something that is going to be distributed to a wide audience then actually fix it rather than just stuff in a kludge that simply tries to work around it.
In this case the problem is known as well as how to fix it.
Avrdude created this issue so the real fix is in avrdude. It is a 6 line patch to avrdude. The change is simple and easy to do.
MANY man days of time have been wasted/lost for something that takes literally minutes to fix.
Once fixed in avrdude, the problem is put to bed and it goes away.
There is no need for any other changes anywhere else. You can do back to back commands or everything in a single command. avrdude will work as it is supposed to work.
--- bill