Bricked Nano burning bootloader?

I was using the Arduino as ISP on a Nano to burn another Nano with the bootloader and then upload as sketch.

This worked about 5 times and then it stopped working. The device signature was coming back as 0x000000. After it had failed I have tried Optiboot and MiniCore which didn't work.

I have replaced all the wires between the two Nanos, added/removed capacitors as suggested for the Mega2560.

My hunt on Google has shown either people successfully burning bootloaders and using the Arduino ISP to upload sketches or people reporting a similar problem to mine and not resolving it.

I hoping someone has travelled down this path and seen the light and would share it here.

Here is some IDE output from an attempt with Optiboot

Cheers Alan


avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\acboo\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf"

         Using Port                    : COM3
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         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 : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000 (retrying)

Error while burning bootloader.
Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

Post a complete wiring diagram of that setup!

Post the command you have used also.
Is the response complete 0x00s? You can switch on the more verbose output by adding -vvvv parameter to find out. Use the command line for this.
If so, there is no response from the target. It points to HW problem: incorrect wiring or target MCU is not working.
Arduino as ISP is pretty reliable if the HW setup is OK.

What does it mean exactly? You do not need any additional parts for Arduino.
The minimum setup for bootloading the ATmega is:

  1. power circuit, decoupling is recommended
  2. reset circuit
  3. oscillator
    Arduinos have all 3 conditions fulfilled. It is obvious the stk500v1 protocol was used so "no reset-proof" capacitor is needed.

Upload what? Via ISP? If you have used ISP the all content of the flash mem has gone.

I may be wrong here, but I seem to recall that there can be a situation where the device cannot be programmed. If the device is programmed and the flags set to use an external clock source, but no external clock is present, then the device cannot be reprogrammed. There's a simple sketch that uses another Arduino to generate a 4MHz (or is it 8MHz) clock that can be used a a clock source.

But that may not be the problem in your situation.

To be clear, the method worked about 5 or 6 times and then the 0x000000 address problem started.

It is unlikely that I have not wired it correctly or followed the correct process because it worked. The essential part of the problem is that the target is no longer being recognised.

The solution, if this exists, will be to FORCE the bootloader onto the target and push through the failure to get a valid target address. The bootloader utilities I have tried have failed.

I did not expect to use a capacitor but seeing as all else was failing I tried it.

The target is now unresponsive to uploading a bootloader or a program/sketch due to this, I assume, target address = 0x000000 situation.

Does this help?

Yes reply is 0x000000

No command, done via IDE

This is maybe silly, but are you sure there is Arduino as ISP sketch in the programmer?

You can try deeper investigation on the target MCU:

  • check the power on the chip,
  • check the oscillation on the XTAL pins.
  • check if the reset pulse is comming from programmer.
    You can do this with any cheap DMM .

Check the wires.

As stated, I replaced the wires and checked for continuity.

Chip has power.

I can check for the reset pulse but I think its working as you can see from the output in the first posting it looks like its a problem with the response.

Standard Nanos. Unlikely to be XTAL pin oscillation. I may put them both on the oscilloscope another day though.

The "programmer" Nano needs a 10µF capacitor from Reset to GND, otherwise it resets when the serial port is opened and the Nano waits for a new sketch to arrive for a few seconds.

How come? The only thing which can reset the programmer is the reset pulse generated by avrdude on serial DTR and RTS line. DTR is used in the circuit. However this is based on the protocol used with avrdude. STK500v1 is without the reset pulse.
Am I missing something?

Yes, the programmer is a Nano. The DTR line is resetting it. As soon as avrdude is opening the serial port it will reset the programmer Nano. The other Nano is resetted by an stk500 command.

Do you have a 3rd nano to use for testing the programmer?

How are the wired connected? If there are not headers on the nano, are the wires soldered?

Was the nano working before you hooked it up to the programmer?

Were you experimenting with the lock bit settings in the fuses? A wrong setting there can disable the ISP programming mode.

I have other Nanos.

Wires connected as per earlier diagram.

Yes all Nanos were working.

No I was not experimenting with fuse settings.

It worked, as expected about 5 times and then stopped whilst doing what I had done 5 times previously.

I am really after how to get the Nano back to life rather mor than how it happened. Of course I am interested in how it happened but I'm currently assuming that the process will be fine with another one because a) it has worked and b) nearly everyone says/shows it working on Google and YouTube.

This is to find out if I can recover should these things happen again.

Already conflicting information as to whether a capacitor is needed on the programmer Nano.

I made it work without a capacitor.

Using a capacitor or not since it bust has made no difference.

How is the wiring attached? An intermittent connection (from the original wiring, before you replaced the wires) could have bricked the processor.

No. If avrdude command is with "-cstk500v1" switch, the avrdude do not send DTR nor RTS. I am using currently v6.3 and older versions v6.x did the same way.

DTR is activated by connecting the device to USB port, opening new terminal, adding the device to the virtual machine (which is practically the same case as connecting the device to USB port) etc.
However, this has nothing with the avrdude. Avrdude do the DTR and RTS e.g with "-carduino", but if Arduino as ISP is used there should be -cstk500v1 in the command. Old IDE versions e.g. 1.0.6 used -carduino so it was problem with this and capacitor did solve it, but it was not problem with avrdude per se.

It works for me with Arduino ISP and genuine UNO R3, Mega R3, Nano (with FTDI, I have no chinese versions CH340) and plenty custom boards ATmega1284P with FTDI FT232RL. All the same way. No capacitor is needed between RESET and GND on the programmer.

EDIT: I forgot mention OS. I am using Windows and Linux with the same behavior.

May be. Can't now tell. Real issue is can I recover the knackered Nano.