I have a problem regarding the bootloader of my Arduino UNO. I´d like to use AVR Dude to solve it. Therefore I bought two USBasp Programmer to upload a new bootloader on my UNO.
Here I've read that they need an update because they were delivered with an older version of the software (this is why I bought two of them). But I am not sure about the correct procedure to update the progammer. In some tutorials I saw that they used a hardware folder which i cannot find in my Arduino folder.
So, i kindly ask if someone could explain me, if this folder is needed and which is the correct procedure to update the programmers and burn the bootloader on the Arduino UNO again.
Hi @jleti. It is not necessary to update the firmware on the USBasp programmer. The firmware they come with will work perfectly well for your use case of performing a "Burn Bootloader" operation with your UNO.
As you might have already learned, there are some enhanced community created versions of the USBasp firmware. These won't provide any benefits whatsoever for your use case, but are useful for some other advanced usages:
Working with chips configured for a low clock speed (including the factory default 1 MHz clock of a fresh bare chip).
On programmers that have the original Fischl firmware, you must short the JP3 jumper to work with these chips. The enhanced firmware adjusts to different clock speeds automagically. Many of the cheap Chinese USBasp programmers come with a proprietary firmware that also adjusts to slow clock speeds.
If you need to use the programmer in those use cases, or if you are up for a challenge and simply think updating the firmware would be a fun project, then by all means go right ahead. I can recommend this firmware:
I have been using it for years on my USBasp programmers and it works perfectly.
But why is even in the product review a large number of comments which say that you need a update because the firmware is not up to date (firmware is from 2011 as mentioned in the comments)?
I am very sorry. This is a little bit confusing. Because they also planned to use the USBasp for burning the bootloader again.
When I just use the Programmer and upload with the programmer I receive this error message:
avrdude: Version 6.3-20190619
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
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. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
The people who write reviews don't necessarily know what they are talking about.
The proprietary firmware on the Chinese USBasp causes the AVRDUDE tool to print a message about updating the firmware. This leads many people to believe that they need to update the firmware even though the Chinese firmware works perfectly well.
In fact, other than not being open source, the Chinese firmware is actually superior to the official Fischl firmware in that the Chinese firmware is able to automatically adjust the clock speed (whereas the Fischl firmware requires the use of the JP3 jumper). So the people who "update" their firmware often end up with worse functionality after the update, and there is no way to then go back to the Chinese firmware that was on the programmer originally.
The part about updating the firmware is a "red herring". Updating the firmware wouldn't help with this problem.
As the error explains, one of the possible cause of this error is the electrical connections between the programmer and the Arduino board being incorrect. However, from looking at your picture, it does appear that your connections are correct.
What is the specific problem with the board that caused you to attempt this "Burn Bootloader" operation?
The other possible cause of the error is that the Arduino board has been physically damaged through being subjected to conditions outside its rated specifications. A "Burn Bootloader" operation can never repair physical damage. Some people do report being successful in restoring their boards from certain non-functional states by burning the bootloader, but it is not clear what sort of conditions could produce those states without also causing permanent physical damage because the bootloader is in a special area of memory that can't be changed through normal use of an Arduino board.
It is definitely worth a try to restore a non-functional board by performing a "Burn Bootloader" operation, but the truth is that often it is a lost cause and the only solution is to buy a new board.
Burning up some hardware is a normal part of experimentation and learning with electronics and everyone doing it ruins a board from time to time.
I understand. Thank you for your comprehensive response!
My problem with my Uno is that although the upload process response that the "upload done" it never get any other code on. Interestingly it still uses some code which I uploaded earlier. I can see this because I used a LCD keypad shield. An this is still running. I found some entries in the internet that this type of problem might be caused by the bootloader. So I guessed it was so.
Have you an idea which problem could cause a behaviour like this?
I don't have any idea of what can cause that. I have seen a few reports of it previously though (example).
I can suggest you try something that might reveal some more information about the problem of the program not running after upload (though not necessarily lead to a solution):
This procedure is not intended to solve the problem. The purpose is to gather more information.
Select File > Preferences... (or Arduino IDE > Settings... for macOS users) from the Arduino IDE menus.
The "Preferences" dialog will open.
Uncheck the box next to Show verbose output during: ☑ compilation in the "Preferences" dialog.
Check the box next to Show verbose output during: ☐ upload.
Check the box next to ☐ Verify code after upload.
Click the "OK" button.
Attempt an upload, as you did before.
Now please reply here on the forum thread with the following information:
Did the upload process succeed this time?
If the upload failed, the full text of the upload output, as shown in the "Output" panel at the bottom of the Arduino IDE window.
This will cause Arduino IDE to verify the data that was uploaded to the board was correctly written to the flash memory on the microcontroller. The other users found that the verification process failed.
It is true that other users who experienced this problem reported that it was fixed by performing a "Burn Bootloader" operation. As I mentioned in my previous reply, I don't have any idea of why doing that would restore the board from a state where it apparently isn't correctly writing uploaded data to flash.
Thank you. I proceeded as you said and this was the error:
The sketch uses 924 bytes (2%) of the programme memory. The maximum is 32256 bytes.
Global variables use 9 bytes (0%) of the dynamic memory, leaving 2039 bytes for local variables. The maximum is 2048 bytes.
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
Fehlgeschlagene Programmierung: Hochladefehler: exit status 1
I proceeded as you mentioned and the IDE retourned this result:
T
he sketch uses 444 bytes (1%) of the programme memory. The maximum is 32256 bytes.
Global variables use 9 bytes (0%) of the dynamic memory, leaving 2039 bytes for local variables. The maximum is 2048 bytes.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x2d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x2d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x2d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x2d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x2d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x2d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x2d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x2d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x2d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x2d
Failed upload: Upload error: exit status 1
This result is different from what you described before:
It was expected that the upload process would fail after enabling the "Verify code after upload" preference, but that failure would have occurred at the verification phase at the end of the upload process whereas this error is occurring during the upload phase.
Likewise, the failed "Burn Bootloader" operation also would not be the cause of this upload failure because the "Burn Bootloader" operation failed at the initialization phase, before any changes to the memory on the UNO's microcontroller were made.
The change to the "Verify code after upload" preference would not cause this upload error so I'm not sure how to interpret this result.
Please check to make sure you have the correct port selected from the Tools > Port menu in Arduino IDE.
This procedure is not intended to solve the problem. The purpose is to gather more information.