From IDE 1.8.x to 2.x: AVR Burn Bootloader still lacks rollback for mid-flash failures

Question

On classic Arduino AVR boards (Uno, Nano, Mega) running the Arduino AVR Boards core with an Optiboot-style bootloader, the Burn Bootloader action in Arduino IDE 2.x invokes avrdude to write the bootloader to flash. The IDE 1.8.x to 2.x transition changed the uploader interface but did not introduce an atomic write, dual-bank rollback, or software-only recovery path for this operation.

When a bootloader flash is interrupted mid-page, the Arduino AVR core does not document a consistent exit-code contract or retry policy for avrdude, so the resulting flash state remains undefined in the official configuration. It is unclear whether a partially programmed page is left corrupt, verified-safe, or indeterminate, and whether the board retains the ability to accept USB serial sketch uploads or instead requires an external ISP programmer to reburn the bootloader.

What flash state does avrdude leave on an AVR target when a bootloader page write fails partway through? Does Arduino IDE 2.x detect this condition and offer any recovery path other than an external ISP reburn?

Tasadduq Burney · Answer

Answer
An interrupted AVR bootloader burn leaves the flash state indeterminate. A page being programmed when avrdude stops can contain a mixture of old and new bits; other pages may be unchanged, erased, or newly written depending on how far the erase/write/verify sequence had progressed. If avrdude exits successfully after verification, treat the flash as verified; otherwise assume the bootloader region is unknown. Arduino IDE 2.x does not add atomic writes, dual-bank rollback, or software-only recovery for Burn Bootloader. It detects the failure only through avrdude output and exit status shown in the console, and it offers no IDE-level rollback or recovery path other than reburning with an external ISP.
Steps for this case

Assume the board may no longer accept USB serial sketch uploads if the bootloader section is damaged.
Connect an external ISP to the ICSP header. The diagnostic detail that changes the next step is whether the ISP can read the device signature; if it cannot, check ISP wiring, target power, and clock before attempting any reburn.
Read the current flash and lock bits or fuse bits, then compare the bootloader region with the expected bootloader hex. Replace the placeholders below:
avrdude -c [programmer] -p [partno] -P [port] -v
avrdude -c [programmer] -p [partno] -P [port] -U flash:r:./current-flash.bin:r
If verification fails or the bootloader region is incomplete, reburn the bootloader and set the board's lock and fuse bits from boards.txt using the ISP. A chip erase may be required if lock bits block programming; chip erase also removes the application sketch:
avrdude -c [programmer] -p [partno] -P [port] -U flash:w:[bootloader.hex]:i
Verify with the ISP, then test a normal USB serial sketch upload.

Version assumptions and uncertainty
This assumes classic Arduino AVR boards such as Uno, Nano, and Mega with the Arduino AVR Boards core in Arduino IDE 2.x, using the bundled avrdude. Exact avrdude behavior, exit codes, and lock-bit handling vary by core and avrdude release; check verbose output for the actual command. The exact post-interruption page state is not documented well enough to treat as verified without ISP readback.
Missing diagnostic detail: can an external ISP read the target's device signature?

From IDE 1.8.x to 2.x: AVR Burn Bootloader still lacks rollback for mid-flash failures

1 answer

Answer

Steps for this case

Version assumptions and uncertainty

Your perspective belongs here.

0 question comments