So, the default bootloader in Arduino is oddly set to erase EEPROM with every reboot, rendering the EEPROM, well, useless.

I found where the fuses are set in the boards.txt file, but getting this configuration change into the chip requires burning an updated booloader.

In the Arduino IDE, there is an option to "Burn Bootloader", but that would be way too easy, and of course, doesn't seem to work.

I can't find any clue on the Internet about how to actually get the bootloader updated in these devices.

So, is it possible to reprogram the bootloader on the Adafruit Feather 32u4 devices?

If so, what's the trick to do it?

  • 1
    Are you sure it erases on every boot and not on every re-flash? Mar 10, 2018 at 22:27
  • Yes, it seems to be every boot, however I am looking to survive re-flash, so I needed to set the EESAVE bit correctly to make this work.
    – Jim B.
    Mar 11, 2018 at 16:39
  • 1
    Update: it looks like i had a bug in my code that was making me think EEPROM data wasn't being saved, so I ended up not needing to burn the bootloader after all. Woot.
    – Jim B.
    Mar 28, 2018 at 21:40

2 Answers 2


"Burn Bootloader" only works if you have a programmer connected to the device. The onboard bootloader in your Feather cannot change the fuses, even though the process may indicate it has done so.

You would have to connect an ICSP (In-Circuit Serial Programmer) to the correct pins (MOSI, MISO, SCK, RESET, VCC, GND). You can use another Arduino as a programmer by uploading a specific sketch to the Arduino to make it an Arduino as ISP.

The normal bootloader on an Arduino emulates this kind of device to allow programming by serial/USB port, but it has limitations. The ICSP process is the native way to get a program onto the AVR chip, and is the only way to set fuses.


This AVR USB Bootloader Datasheet states on page 3:

• Boot Reset Fuse The Boot Reset Fuse (BOOTRST) can be programmed so that the Reset Vector points to the Boot Flash section start address after reset. Once the user code is loaded, a bootloader command (“start application”) can start executing the application code. Note that the fuses cannot be changed by the MCU itself. This means that once the Boot Reset Fuse is programmed, the Reset Vector will always point to the Bootloader Reset and the fuse can only be changed through the serial or parallel programming interface. The BOOTRST fuse is not active in the default factory configuration.

That document also references AVR282: “USB Firmware Upgrade for AT90USB” (Note, I could not find this on the Atmel website.) This document details the FLIP program, at Atmel tool for uploading firmware over the USB DFU interface and setting configuration settings, etc.

This doc has a FAQ section which states:

  1. Can I modify the fuse bits using Flip? • No, Flip cannot modify the fuse bits. To modify the fuse bit you can use either the JTAG ICE MKII, the AVRISP MKII, or parallel programming

So, while this may not be a definitive answer, it appears at this time that "burning fuses" cannot be done over USB on the 32u4. If that's not the case, I'm sure the site would welcome the new info.

  • Note that the question is about a 32u4, not a traditional Arduino, so I believe there are some hardware-assisted DFU options in addition to ISP. Mar 11, 2018 at 3:15
  • Not long after I asked this question, I had a "duh" moment and and realized I had a JTAGICE3 in my drawer. Once I got the pinout right, and overcame a problem with macOS grabbing the device, I was able to cobble a way to get the bootloader to work. I'll post a complete answer here later today so everyone gets the benefit.
    – Jim B.
    Mar 11, 2018 at 16:37

In my case the 32u4 (Lora32u4II) failed after uploading big firmware. Not responsive.

Fortunately I have the buspirate 4 with firmware 7.0. And during this time I discovered that the BusPirate is not able to power the board to reflash the firmware. But if I connect the board over USB and then the cabling as described:

MISO              MISO
MOSI               MOSI
CLK                SCK
GND                GND
CS                 RST

And I use arduino ide to upload a new bootloader it starts to work again. So. I wonder why the firmware update locked the board while there's enough space. And why powering over 5v doesn't get it to work on buspirate + arduino ide.

I leave info for others that have same problem.

I discovered that using this method, even if slower, I can skip bootloader, leaving more room for my firmware...

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