A few days ago I ran into a warning on SparkFun that a certain Arduino board could be
bricked if one attempted to load a sketch set to the wrong board type.
I said how dare they promote such a shoddy board.
Sparkfun support kindly informed me this is the case with any of the boards which you attach
serial support externally.
So I poked my head up and looked around, surveying many available postings on
bricking the likes of pro micros and pro minis. I see a lot of activity and a lot of
instructions on restoring bootloaders post "bricking".
Not much on the "whys".
In four years I have not had to do this despite having used a number of Pro Mini, Micros, and Leonardos. I just did my first bootloader programming only because I bough some blank 328p ICs.
I understand how a sketch itself can interfere with subsequent sketch downloads
but not how the download of a sketch with a wrong board type set in the IDE.
Is it electrical or bootloader or something else?
Are the bootloaders aware of what board they are on
such as to reject a download issued with the wrong board setting?
The upload will complete successfully but then the board will no longer show up in the Tools > Port menu and you won't be able to upload again. There are two ways to fix it:
Do an upload and then press the reset button(or momentarily ground the reset pin if the board doesn't have a reset button) when the upload is in the "PORTS (..." stage.
Burn the bootloader using and ISP.
I believe the reason for this issue is that because you started the upload for Uno the sketch is compiled for ATmega328P. If you had left the board selection as Uno then the upload would have failed but because you changed the board selection to Leonardo it causes a file compiled for the wrong MCU to be successfully uploaded. Because the ATmega32U4 boards don't have a separate USB-serial chip as the other Arduino boards do they need to have code running on them to create the serial port and also to do a reset when there is a connection to that port at 1200 baud. This is why sketches compiled for these boards use significantly more memory. So the sketch compiled for the wrong board doesn't contain that necessary code and then next time you try to upload the MCU never resets, thus the bootloader is never activated and the upload fails.
As for bricking a pro mini, I don't think that could happen from uploading a sketch compiled for the wrong board. You would have to actually corrupt/overwrite the bootloader and I don't think that's possible. That's one of the reasons why I don't recommend using the ATmega32U4 based boards unless you specifically need their special capabilities.
The solution is quite simple. The Arduino IDE needs to be changed so that the board selection at the time the upload button is pressed is always used for compilation and upload, regardless of any changes to that selection after that time. It may seem like it would be obvious not to change the board selection but not only are beginners likely to do this, I've even done it a couple times even though I should definitely know better. Much better to make it so it's impossible to do something like this with the Arduino IDE.
No, because you switched to the ATmega32U4 board before the upload started(but after the compilation started) so the avrdude command specifies -patmega32u4 but the hex file it uploads was compiled for ATmega328P.
Overwriting boot loader in a system where the user is dependent on the bootloader and has no other way to program the device
Selection of a clock source (in fuse bits) that is not actually present
Disabling SPI programming and not having access to a high-voltage programmer
Applying voltage or sourcing/sinking current in excess of published maximums
Only the last one actually constitutes permanent damage, but most people are dependent on an "easy mode" such as the Arduino bootloader, so the first 3 will render the chip as good as dead for those people.
MicrocontrollerGuy:
Causes of "bricking" in AVR microcontrollers:
Overwriting boot loader in a system where the user is dependent on the bootloader and has no other way to program the device
Selection of a clock source (in fuse bits) that is not actually present
Disabling SPI programming and not having access to a high-voltage programmer
Applying voltage or sourcing/sinking current in excess of published maximums
Only the last one actually constitutes permanent damage, but most people are dependent on an "easy mode" such as the Arduino bootloader, so the first 3 will render the chip as good as dead for those people.
Is it possible to cause any of those by uploading a sketch with the wrong board selected?
A bit off topic because it's not related to wrong board selection, but here's a fairly common way that boards get "bricked":
How to "brick" any non-Uno ATmega328P/ATmega168 based Arduino board(and Mega 1280 too?) running the standard bootloader included with the Arduino IDE:
Upload this sketch:
#include <avr/wdt.h>
void setup() {
 wdt_enable(WDTO_15MS);  //the timeout value used is irrelevant
}
void loop() {}
Since the standard "ATmegaBOOT" bootloader doesn't clear the appropriate bit of the MCUSR register the board goes into an endless reset loop, preventing any further uploads until you reburn the bootloader(ProMini: Reboot loop when using watchdog · Issue #150 · arduino/ArduinoCore-avr · GitHub). This doesn't affect Uno because it uses the optiboot bootloader which doesn't have this bug. I highly recommend replacing the bloated, buggy bootloader on the non-Uno ATmega328P/168 boards with optiboot, either by using the Uno bootloader for ATmega328P@16MHz or using MiniCore for other hardware configurations.
