nomadholdings.blogg.se - Arduino avrisp driver problem

All it does is provide a loop that if the specified USB programming device is not found on the USB, it waits a few milliseconds and looks again. If you read the links I posted above you can see the actual fix. The fix is just a couple of lines of code. The real solution is to actually fix it in avrdude:

This will also slightly speed up the operation. I recommend doing this even if avrdude is fixed as there is no reason to do two back to back avrdude commands when it can all be done in a single command. This is the solution that optiboot switched to for its makefiles and build scripts. This is a preferred work around since it avoids the back to back avrdude command issue since it does everything in a single command.

Change the IDE to use a single avrdude command vs two.

Furthermore, this is what was already being doe and the problem is how long is long enough? The amount of time is dependent on the OS and the speed of the processor and the speed of the USB device. This is a dumb way to handle it as it adds a blind delay even when it is not needed.

add delays in the IDE between back to back command.

There are ways to work around it without modifying avrdude: The problem is that avrdude is not then doing what is necessary to properly recover from its libusb work around the next time avrdude starts up. It is avrdude that chose to work around a libusb bug by resetting the USB. This is a avrdude bug and needs to be fixed in avrdude. The problem is that if your run avrdude immediately after just running avrdude, the device you are using may not have completed it's USB re-enumeration since avrdude just kicked it off the USB by resetting the USB when the previous avrdude command finished. When avrdude starts up, it does one quick look for the USB device specified and when it doesn't see the device, it bails out. The atmel devices like the MKII and the Dragon take a while (second or two) to complete their re-enumeration with the OS as they seem to internally reset themselves when the USB is reset.Īvrdude does not attempt to look very long for devices on the USB when it starts up. Until a device finishes re-enumerating, it essentially does not exist to any application that tries to look for it. Resetting the USB means that every single device on the USB must re-enumerate after avrdude exits. But regardless, it is avrdude that is resetting the USB which is what is causing this issue. It is doing this because of an issue in libusb. I'll summarize here again for those that won't go read the information in the links I provided.Īvrdude is intentionally resetting the USB just before it exits. If you read information in the links that I provided, I detailed in great detail what the problem is. Nor is the IDE inducing this issue by not waiting long enough between avrdude commands. At least I can make a batch file for this as I have 350 boards to program and this would not have been good to do with a 19/20 failure rate. So definitely a timing issue where the second command is issued too soon. I ran these as separate commands in a command prompt and boom, it works! I have also noticed that if I click "burn boot loader" in Arduino IDE enough times it does work about 1 in 20 times. "C:\Program Files (x86)\Arduino/hardware/tools/avr/bin/avrdude" -C"C:\Program Files (x86)\Arduino/hardware/tools/avr/etc/nf" -v -patmega328p -cstk500v2 -Pusb -Uflash:w:"C:\Program Files (x86)\Arduino\hardware\arduino\avr/bootloaders/atmega/ATmegaBOOT_168_atmega328.hex":i -Ulock:w:0x0F:m

"C:\Program Files (x86)\Arduino/hardware/tools/avr/bin/avrdude" -C"C:\Program Files (x86)\Arduino/hardware/tools/avr/etc/nf" -v -patmega328p -cstk500v2 -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xFF:m I turned on verbose mode as you said and copied the two instructions: