bootloading with Nano stopped working and the -F switch

Hi guys,

I have a strange problem. I have been burning bootloader to my custom boards for more than 2 years now, always using the same setup, an Arduino Nano with the ICSP signals (reset from D10), target chips are Atmega328p devices. It worked all right, having burnt hundreds of boards already. And now it just stopped, and I did not update anything (in fact still using IDE 1.6.10, with Board Manager 1.6.17).

Sometimes the signature 0x000000 comes, OK I know that the connection to the target board is bad. But even if the connection is sound, avr finds always reasons not to burn the bootloader.

I even tried to re-burn boards which work perfectly, and are already bootloaded. No luck! I'm in a difficult situation, as I always depended on this already working solution and out of a sudden it stopped performing its task.

I attach a few logs. It seems sometimes avr complains about the device signature. OK, I can solve it by editing the conf file. But even if this test is passed, afterwards there are other stuff checked, all with the result that at the end the avr refuses to burn the bootloader.

I also would like to learn how to use the -F switch. I'm really willing to experiment with it, knowing the risk involved. Is there a way to activate it somewhere in such a way that the IDE always use -F?

I'm grateful for any hint what could cause this sudden problems.

Thanks!

bootload_fail_1.txt (4.1 KB)

bootload_fail_1.txt (4.1 KB)

bootload_fail_3.txt (4.1 KB)

code_upload_success.txt (3.26 KB)

Protonerd:
I also would like to learn how to use the -F switch. I'm really willing to experiment with it, knowing the risk involved.

The easiest way to experiment is:

• File > Preferences > Show verbose output during: > upload (check) >OK
• Tools > Burn Bootloader
• After the Burn Bootloader process finishes, scroll up the black console window at the bottom of the Arduino IDE until you see the avrdude commands the Arduino IDE ran to burn the bootloader. On a successful Burn Bootloader there will be two commands. The first sets the fuses. The second flashes the bootloader file.
• Copy and paste those commands to the command line and modify them as you like.

Protonerd:
Is there a way to activate it somewhere in such a way that the IDE always use -F?

Yes. The avrdude commands are defined in platform.txt. You can modify those definitions as you like. There are a few things you need to be aware of:

• In the case of Arduino AVR Boards, when you update to a new version via Boards Manager, it's installed to a different location than the original version, which is bundled with the Arduino IDE. The original version will still be in place but not used. So if you're editing the wrong platform.txt it will have no effect.
• You need to restart the Arduino IDE before changes you make to platform.txt will take effect.
• Whenever you update to a new version of the hardware package (or the Arduino IDE in the case of the bundled Arduino AVR Boards), the changes you made to platform.txt will be lost.

The easiest way to find the active hardware package location is as follows:

• Select a board from the hardware package from the Tools > Board menu
• File > Examples > SPI > BarometricPressureSensor
• Sketch > Show Sketch Folder
• Move up folder levels until you reach the one that contains platform.txt

Thanks pert for the promt answer! I will try out the steps you suggested and feed back about the results!

About Nr.3:

After the Burn Bootloader process finishes, scroll up the black console window at the bottom of the Arduino IDE until you see the avrdude commands the Arduino IDE ran to burn the bootloader. On a successful Burn Bootloader there will be two commands. The first sets the fuses. The second flashes the bootloader file.

I see the first command, but since currently I cannot seem to burn any bootloader successfully, I will not see the 2nd command...

On my computer, here's the command that sets the fuses:

C:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14/bin/avrdude -CC:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14/etc/avrdude.conf -v -patmega328p -cusbasp -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m

And here's the command that flashes the bootloader:

C:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14/bin/avrdude -CC:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14/etc/avrdude.conf -v -patmega328p -cusbasp -Pusb -Uflash:w:C:\ArduinoIDE\arduino-1.8.7-td\hardware\arduino\avr/bootloaders/optiboot/optiboot_atmega328.hex:i -Ulock:w:0x0F:m

So you can see that the difference is only the last part of the commands.

In the first we have:

-e

which erases the memory. Then:

-Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m

which sets the lock fuse bits according to bootloader.unlock_bits and sets the extended, high, and low fuses.

In the second we have:

-Uflash:w:C:\ArduinoIDE\arduino-1.8.7-td\hardware\arduino\avr/bootloaders/optiboot/optiboot_atmega328.hex:i

which flashes the bootloader. Then:

-Ulock:w:0x0F:m

which sets the lock bits according to bootloader.lock_bits.

You should be able to extrapolate what the second command should be from your first command.

An potentially interesting thing to know is that it's not actually necessary to run this in two separate commands. They can be combined into one. In my case:

C:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14/bin/avrdude -CC:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14/etc/avrdude.conf -v -patmega328p -cusbasp -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m -Uflash:w:C:\ArduinoIDE\arduino-1.8.7-td\hardware\arduino\avr/bootloaders/optiboot/optiboot_atmega328.hex:i -Ulock:w:0x0F:m

Documentation of the AVRDUDE options:

Dear pert!

Thanks again for your valuable help, I tried the command lines, especially the one where the two commands are united in one. I also did few things to rule out diverse influences:

• I cleaned up my PC from multiple versions of the Arduino IDE, now I only have 1.8.7
• I checked again the cap between RST and GND on the Nano I use to bootload my custom boards, I even exchanged the old one
• I used 2 boards which failed to be bootloaded from older batches as well as one untouched, virgin device from a new run

Following logs are from the same device (fresh, virgin one):
If I use the IDE, I still get this one:
(see ArduinoIDE_bootload_flashNot_OK.txt)

Then I switched over to the command line version you've sent me, adapted to my environment and it seems I had more luck with it:
(see attachment commandline_bootload_flashOK.txt)

However when I connect the board via USB and try to upload a sketch defining Arduino/Genuino Uno as board, I get the sync error:

Sketch uses 13484 bytes (41%) of program storage space. Maximum is 32256 bytes.
Global variables use 1518 bytes (74%) of dynamic memory, leaving 530 bytes for local variables. Maximum is 2048 bytes.
C:\Users\MunkaGep\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino2/bin/avrdude -CC:\Users\MunkaGep\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino2/etc/avrdude.conf -v -V -patmega328p -carduino -PCOM22 -b115200 -D -Uflash:w:C:\Users\MunkaGep\AppData\Local\Temp\arduino_build_106434/DIYino_Testsketch_Pro.ino.hex:i 

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:\Users\MunkaGep\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino2/etc/avrdude.conf"

         Using Port                    : COM22
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x8a
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x8a
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x8a

So all in all it seems the bootloader is flashed, but still no luck interacting with the boards (all 3 I tried behave the same). The only thing I did not try so far is to replace the Nano I use for the bootloading, but it is very unlikely the issue.

ArduinoIDE_bootload_flashNot_OK.txt (4.21 KB)

commandline_bootload_flashOK.txt (4.74 KB)

OK, I found out, that following the through clean-up now I'm not able to interact with any of my boards, no matter what kind of I connect to, the same sync message appears. First I suspected the FTDI drivers gone missing, so I deinstalled all of them and reinstalled them from here: How to Install FTDI Drivers - SparkFun Learn

But still the same. Somehow I feel stuck. Any ideas?

Now I can program previously working boards, problem was that I let the IDE update to the newest board definition 1.6.23. ow I downgraded to a stable 1.6.12, and upload works
So I assume everything is OK with the drivers.

Using the command line provided by pert I now tried to bootload one of my not working boards with an old nano bootloader. Same result, no sync... it is mysterious.

Using the command line provided by pert I now tried to bootload one of my not working boards

After using the command line your fuses were reading .

avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK (E:FD, H:D9, L:62)

You need to burn the fuses. Add this to your command line before the bootloader hex file.

-e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xFF:m

Now that you are using IDE 1.8.7 remember to choose old bootloader when burning bootloader for a Nano.

With the additional line from kprims now I could successfully burn a few boards again. Interestingly the IDE still refuses to burn any of my boards, although it worked well for more than 2 years... Is there any possible reason why the IDE triggered bootloader burning is disabled?

Some other boards I could not burn at all, I'm still not sure what the matter with them.

So thanks guys for all your help, I really appreaciate what the community does for its members!!! Simply GREAT!

You're using the "Arduino as ISP" programmer, right? Starting with Arduino AVR Boards 1.6.22/Arduino IDE 1.8.6, the protocol used by that programmer was changed from stk500v1 to arduino:

The reason for this was to add support for using the ATmega32U4 (and perhaps other native USB boards?) as an Arduino as ISP. Unfortunately, the reset behavior of the arduino protocol can cause other boards that previously worked as Arduino as ISP to no longer work:

In that case, the fix is to disable the auto-reset circuit on the Arduino as ISP board by adding a 10 uF capacitor between the reset and ground pins.

More information:

Thanks pert and sorry, I missed this one... I have th cap on my setup right from the beginning. Now I can burn the bootloader using avrdude, which is fine for me. IDE still refuses to do the job, but I do not care as long as the other method works. The boards I cannot bootload I conclude must be dead due to a completely different reason. Would be nice to find out, as it affects ~5% of them, but it is a problem for another day.

Protonerd:
Now I can burn the bootloader using avrdude, which is fine for me. IDE still refuses to do the job

Are you running the exact same command from the command line as the IDE is running?