Old Nanos stopped responding to boot loader

Hi folks,

I'm recording this just in case this issue stumps anyone else.

I've been using a whole bunch of Nanos (and the really cheap Chinese knockoffs) for ages then all of a sudden they stopped uploading.

Constantly got errors as detailed below.

It took me a while to find - but there was a new boot loader released with the newer Arduino IDE - under Tools|Board you'll now see a new Processor option, eg Arduino Nano (Old boot loader). If you get stuck - try selecting that option.

This fixed it for me.

------------------ ---------------------
avrdude: Version 6.3, compiled on Jan 17 2017 at 11:00:16
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "/home/vince/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino9/etc/avrdude.conf"
User configuration file is "/home/vince/.avrduderc"

Using Port : /dev/ttyUSB0
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x49
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x4c
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x49
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x39
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x33
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x34
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x31
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x20
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x54
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x65

avrdude done. Thank you.

An error occurred while uploading the sketch

------------------ ---------------------

old-bootloader.png

Thank you!
Been strugling with this all afternoon, and my only option was to re-install the IDE, and remain at boards version 1.6.20. Not even downdrading the boards would fix it.

Thanks for the info. Arduino Nano (Old boot loader) only showed up on my Windows7 machine, not on two other Windows 10 machines. But it worked for me. Your post helped me not have to wonder about that.

I’ve uploaded optiboot to my Nanos, so I can use interrupts. I just select board type as UNO and burn the bootloader using my programmer.

Got this last night got blocked for a while.... :frowning:
Do you know where are the release notes of the new bootloader ? Just to know if I should upgrade my two nanos ?

tks

Hi, same problem here. Solved when I downgrade to AVR Boards 1.6.20.

ocsav:
Do you know where are the release notes of the new bootloader

It's actually not a new bootloader, it's just new to the Nano. It's the same excellent Optiboot bootloader that has been used on the Uno for years. The change was made in Arduino AVR Boards 1.6.21. There are no release notes for it but you can see the change here:

And see all changes to the Arduino AVR Boards hardware package (not the toolchain) here:

And to the people saying they had to downgrade to Arduino AVR Boards 1.6.20, I guess you didn't read the post carefully. You only need to select Tools > Processor > ATmega328P (Old Bootloader).

Making the "new bootload" the default is going to result in a lot of people having problems. :frowning:

Yes, I think we're going to see a lot of forum posts about this. I wonder how long before the cloners will get wise and start using Optiboot on their Nanos.

Possibly making things more complicated is that the new nanos are still shipping with fuses set for a 2 kB boot section, negating one of the biggest benefits of using Optiboot. I suspect they will correct that soon but I'm not sure what the implications are of having some Nanos with ATmegaBOOT and 2 kB boot section, some with Optiboot and 2 kB boot section, and some with Optiboot and 0.5 kB boot section.

Yup! I got this, too. grrrrrrrr!

I went back to "Arduino AVR Boards Built-In by Arduino version 1.6.20" from 1.6.21 It works now, but will the old version of this code be compatible with yet to be newer versions of the IDE?

Tools-->Board: "Arduino Nano"-->Boards Manager...

OldSurferDude:
I went back to "Arduino AVR Boards Built-In by Arduino version 1.6.20" from 1.6.21

Why? It's so much easier and faster just to do Tools > Processor > ATmega328P (Old Bootloader).

OldSurferDude:
will the old version of this code be compatible with yet to be newer versions of the IDE?

No guarantees. Even if it does, if you confine yourself to perpetually using an outdated version of Arduino AVR Boards then you miss out future improvements and bug fixes.

Pert,

Thank you for the information. I have found it useful and have successfully employed it.

As you can see next to my name I am considered a "Newbie", thus I am not aware of every subtlety of the Arduino IDE. I hope this answers your question

Why? It's so much easier and faster just to do ...

Your first answer obviated the second question, thus, no response was necessary, though the redundancy ensured that the information was received. Thank you again for taking the time to add that.

pert:
And to the people saying they had to downgrade to Arduino AVR Boards 1.6.20, I guess you didn't read the post carefully. You only need to select Tools > Processor > ATmega328P (Old Bootloader).

I have 2 nanos (clones) and more 2 on the way, I think I'll upgrade them all to optiboot.
I have an USBASP and the converter from 10 to 6 pins, so I should have all I need to do the upgrade.
Can it be done from the IDE ? Maybe selecting the processor as ATmega328p (not the Old bootloader option I'm using now) and programmer USBASP and then just selecting the "burn bootloader" option ? Do I need to do something to get the fuses right ?

ocsav:
I have 2 nanos (clones) and more 2 on the way, I think I'll upgrade them all to optiboot.

That's what I do with all mine. Other than the complexity of the process for a beginner (which is mostly caused by people using "Arduino as ISP" programmers instead of a dedicated programmer), it's really a win all around.

ocsav:
Maybe selecting the processor as ATmega328p (not the Old bootloader option I'm using now)

No, if you do that then you get the outdated bootloader that was replaced by Optiboot. That bootloader takes up 2 kB of your flash memory and has a bug that causes an endless reset loop after a watchdog reset. If you have an ATmege328P-based Nano, rather than the rare ATmega168 based ones, then the process is this:

  • Connect your programmer to the Nano
  • Connect your programmer to the computer
  • Select Tools > Board > Arduino/Genuino Uno
  • Select Tools > Programmer > USBasp (or whichever is appropriate if using a different programmer)
  • Tools > Burn Bootloader

After doing that you only need to remember to always have Tools > Board > Arduino/Genuino Uno selected when use use the Nano.

There is one tiny catch. The Nano actually uses a different variant file (named eightanaloginputs) than the Uno's variant (standard). This is because the Uno does not have pins A6 and A7 broken out. All that eightanaloginputs file consists of is this:

#include "../standard/pins_arduino.h"
#undef NUM_ANALOG_INPUTS
#define NUM_ANALOG_INPUTS           8

So there is no difference from the Uno other than the value of NUM_ANALOG_INPUTS. That's actually not a big deal because NUM_ANALOG_INPUTS isn't really used anywhere. The only place I've seen it is in the Firmata library. It's not used anywhere in the Arduino core or in any of the other official Arduino libraries.

If this is an issue for you, you can simply use MiniCore:

which has Optiboot and also defines NUM_ANALOG_INPUTS as 8. MiniCore also provides support for the ATmega168 in case you don't have the ATmega328P Nano.

ocsav:
Do I need to do something to get the fuses right ?

Tools > Burn Bootloader actually does two things: Set fuses, then flash the bootloader file to the microcontroller. The correct fuses are already defined in the boards.txt entry for the board you have selected from the Tools > Board menu. So you don't need to worry about it unless you want different fuses from the standard ones. If so you could edit boards.txt as required or if you're using MiniCore it adds extra Tools menus that let you easily configure the most common fuse settings from inside the Arduino IDE.

Hi

I was able to flash it with Uno and MiniCore bootloaders. I had an hard time making USBASP work, in the end it was the driver, I had to set it up with the libusbK driver, but I don't know why, thanks God by programs like ZADIG.

And now I have to find a way of upgrading USBASP firmware, it works but avrdude says

avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.

So now I'm looking into the process of upgrading it, I only have one usbasp but I have one USBtinyisp v2.0 and several flavors of ftdi equivalents (yes, I kinda collect programmers, if they are cheap I buy one, you never know when you need it).

update: after some more reading it looks that that error is not important and some things should not be messed with unless it is really needed (if it is not broken...) .
I tried programming the Nano bootloader with a USBtiny instead of the usbasp... It works exactly the same, just choose a different programmer from the menu.
In windows I used ZADIAG again and installed the libusbK driver.

ocsav:
I had to set it up with the libusbK driver

Same here.

ocsav:
thanks God by programs like ZADIG.

Yes!

ocsav:
it looks that that error is not important and some things should not be messed with unless it is really needed (if it is not broken...) .

I'd tend to agree. For the Nano there is no reason to upgrade your firmware. There is an issue with the regular USBasp firmware and the ATmega2560:

but it's pretty rare that you would actually need to do an Upload Using Programmer with the ATmega2560 since it has so much program memory that the part taken by the bootloader is not really significant. The regular USBasp firmware works fine for burning bootloaders to the ATmega2560.

I also have a programmer collection but I much prefer my USBasp to my USBtinyISP because the only minor limitation of the USBasp can be easily overcome but I'm not aware of any means by which it's possible to do the same for the USBtinyISP.

I'm not a big fan of the mega anyway. Thanks a lot pert for the help.

I've seen a lot of tutorials and forum threads about the USBASP drivers and no common solution, I wonder if there is a 'right' answer or if we just try different drivers until avrdude starts working.

For the record, I'm running win 7 64-bits, and using libusbK driver for USBASP and USBtiny 2.0

One more question, is it possible to retrieve the firmware version from the USBASP using avrdude ?

I think the cause of the driver confusion is that the answer has changed over time and also differs from person to person somehow. The official firmware comes with the libusb-win32 driver and that used to work fine for me until Arduino's release of AVRDUDE 6.3. Then it stopped working until someone was kind enough to point me to libusbK. Other people can use AVRDUDE 6.3 with libusb-win32 no problem. In fact I can use the official build of AVRDUDE downloaded from their web page with libusb-win32. I reported this to Arduino:

but it was never taken very seriously because nobody except me could reproduce the problem.

I've never heard of anyone having problems with libusbK so I think that's always the best driver choice but advice to use libusb-win32 is not specifically wrong because for the person writing the advice I'm sure that driver worked fine.

Who dicieded to change our Nano's? This really screwed me tonight with a huge project.

Can some one write some directions on how to fix this issue with the nano copies. Mine have probably the older boot loader and the CH430 chip.

It was already explained multiple times in this thread:
Tools > Processor > ATmega328P (Old Bootloader)