When the Leonardo was introduced, I think, I've read some articles about being cautious to do some things, that could cause it to not load any new sketches any more, so one has to rewrite the bootloader. Because I plan to use power-saving options, e.g. to disable unused hardware components like USB port, I fear to do something wrong.

One Leonardo-delicacy I've found so far:

  • if interrupts are disabled, uploading new sketches fails unless one presses the Reset button as soon as the Arduino IDE is showing "Uploading..."

What stuff (except of the usual hardware-related thinks like connecting output-configured pins to fixed potentials) could damage the controller or require to reflash the Leonardo with a fresh bootloader?

  • Generally, Arduinos are impossible to brick via software unless messing with the fuses on the chip (or designing a robot to destroy the board :D). Jul 20, 2014 at 18:57
  • 1
    The bootloader is always run before your own program. So when you press the reset button the bootloader will start and you can upload you new program, even if the your old program was faulty. Disabling certain components is just temporarily, and they should restore when the device is reset. By changing the fuses you can make certain option permanent, so try to avoid having to changing those.
    – Gerben
    Jul 21, 2014 at 11:50
  • 2
    Gerben, could you please add your comment as answer?
    – Thomas S.
    Jul 22, 2014 at 4:31

4 Answers 4


If you upload a program that changes the speed of the USB core it would be almost bricked. What would happen is this:

  1. Power on, boot loader starts, USB device enumerated on PC.
  2. A few second later program start, USB core speed changed, USB device disappears from PC

The issue here is that not only do you have to hit reset to program, after the reset you have to quickly select the right com port and then upload before the program starts.

The Redbearlab Blend Micro requires a USB core speed to be set in the user program. In their setup instructions there is a step to edit the Arduino main.cpp and add a section to do so. If this step is missed, the above problem happens.


I managed to brickwall an ATMega128RFA1. The bootloader, and the software I uploaded in it, were working fine. But it was impossible to erase/write the ROM.

After checking for what have happened, I discovered in the datasheet that some fuses in the AVR core are intended to protect accidental writing on the ROM. Some kind of security fuses.

I never found the bug which wrote in these bytes (as it was a really big program and we were 3 peoples involved in the coding) but yeah, we just blew a fuse and lost an MCU because of a bug.

As for the leonardo, several things could happen, but none of these can brickwall your board unless you blow one of this protection fuse.


It is possible, with some really clever code, to exploit the bootloader to overwrite itself.


The solution is actually conceptually fairly simple. A bootloader, by its very nature is designed to download new firmware to the device. Therefore it will contain at least one spm instruction. Because the spm configuration register must be written no more than 4 cycles before the spm instruction it means there are very few sequences that practically occur: just sts, spm or out, spm sequences. So, all you need to is find the sequence in the bootloader section; set up the right registers and call it.

However, it turned out there was a major problem with that too. The V-USB self-programming bootloader's spm instructions aren't a neat little routine, but are inlined into the main code; so calling it would just cause the AVR to crash as it tried to execute the rest of the V-USB bootloader.

Nasty, but again there's a solution. By using a timer clocked at the CPU frequency (which is easy on an AVR), you can create a routine in assembler which sets up the registers for the Bootloader's out, spm sequence; calls it and just at the moment when it's executed the first cycle of the spm itself, the timer interrupt goes off and the AVR should jump to your interrupt routine (in Application space). The interrupt routine pops the bootloader address and then returns to the previous code - which is the routine that sets up the out, spm sequence. This should work, because when you apply spm instructions to the bootloader section the CPU is halted until it's complete.

So basically, you can do some fancy programming, and get the bootloader to hose itself, rendering the MCU useless without a dedicated programmer.


The one I know of is making the Leonard act like a USB mouse that flaps everywhere and types random keys so you can't reprogram it without doing some kind of trick to get around it. But they mention this on the api docs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.