# What is the purpose of a microcontroller bootloader? [duplicate]

From my understanding, for a common microcontroller (e.g. AVR, PIC), there are generally two methods of programming its flash memory.

1. Using a programmer: In-Circuit Serial Programming (or some variant?)
2. Some form of a bootloader, to which an external device communicates, ultimately allowing the microcontroller to flash its own memory.

Certainly there must be a very good reason to use a bootloader, else its current widespread use would be very odd. I just haven't seemed to have fully grasped it yet.

Is it that a programmer is expensive? But then, there are Arduinos (ATmega microcontroller) which can function as programmers. Is the cost of one extra IC enough to warrant the use of a bootloader? If I'm not mistaken, the latest Arduinos get rid of the FTDI chip altogether, replacing it with an ATmega processor that does the USB to serial interfacing. Surely it would be possible to integrate the programmer's function on this IC for instance?

Or take for example, the PIC microcontroller. There is something I've seen called the JDM programmer. If something like this, with virtually no active components, can program a PIC then,

1. Why use a bootloader at all?
2. What is the purpose of the relatively much more complex PICkit (aside from robustness)? Debugging capability?

## marked as duplicate by old_timer, Asmyldof, Bimpelrekkie, Olin Lathrop microcontroller StackExchange.ready(function() { if (StackExchange.options.isMobile) return; $('.dupe-hammer-message-hover:not(.hover-bound)').each(function() { var$hover = $(this).addClass('hover-bound'),$msg = $hover.siblings('.dupe-hammer-message');$hover.hover( function() { $hover.showInfoMessage('', { messageElement:$msg.clone().show(), transient: false, position: { my: 'bottom left', at: 'top center', offsetTop: -7 }, dismissable: false, relativeToBody: true }); }, function() { StackExchange.helpers.removeMessages(); } ); }); }); Apr 17 '16 at 13:07

• to initialise hardware or load code from an external source to internal storage – Alex Apr 15 '16 at 15:26
• To add to some of the answers here, regarding "expensive": for some MCUs (AVR, STM8/32, ...) programmers are cheap. You can get an AVR programmer for $15 or less. However, for other MCU families (Kinetis, for example), programmers can be upwards of$100, and programmer/debuggers that can program many ARM families can be \$500+. But as other's have said, it's mainly about convenience, remote updating, and eliminating external hardware. – uint128_t Apr 15 '16 at 15:43

The main purpose of a bootloader is to allow updating the firmware through interfaces other than the default hardware interface. For example, this allows updates via communication channels that the application uses otherwise for its own purposes, which means that you can do remote in-system updates without requiring physical intervention at the remote site.

Once you have this capability, you need zero additional hardware, which makes it the method with the lowest recurring cost, and this is why hobbyist systems like Arduino use it. It also provides a small amount of marketing lock-in, because now you need to buy your AVR chips with the bootloader already programmed into them.

There are some scenarios where a boot loader doesn't add much value. You are right if you have a couple of boards you can certainly attach the programmer and flash the code again. If you are a hobbyist with a couple of boards or you have even a small production you can do it this way.

The bootloaders have more sense in scenarios where physically connecting a programmer would be less practical. Finished products that are already deployed for example is one of those scenarios

Generally when you have an electronic product you don't let a "debug" or "programming" port exposed. You only have like an Ethernet, or serial, or RS485, or CAN or wireless on your product.

Also what if you have several tens or maybe hundreds of them already sold/deployed and you have a firmware update?

Instead of going one by one opening the enclosures, attaching the programmer, programming, close the product case and so on, you can just use one of your current product's existing interfaces to program it.

It's even better when you have "connected" devices with for example ethernet or any kind of wireless. If you put a wireless module into whatever your product is you can use that wireless communications with a bootloader to update the code, this way you can update several devices at the same time and without touching them.

And it becomes a dream feature if your devices are connected to the internet. That way you can update the firmware of everything with just one click, as your phone gets its updates.

For a hobbyist maybe it does not have much sense to use a bootloader, but from a business perspective where you are actually selling devices it has lots of sense since it saves time, adds much convenience to the process and if your users have contact with your device you don't have to sell them programmers just for firmware updates (or make them buy the programmers otherwise). And what if your devices are the same functionally but with different microcontrollers? you would have to determine who has what in order to send or sell the correct programmer, it becomes a nightmare!!

Instead of this you just put a USB port on it and everything gets hidden from the user, everybody knows how to connect a USB to the PC, copy one file to it and attach it to another device, but no normal user knows what the heck is a P&E debugger, a PICKit or a Segger J-Link.

Sorry if this is a bit confusing, English is not my language and maybe the redaction is a mess, but I hope you get the idea.

Cheers!!

• Good answer, maybe a bit verbose. Your English is fine (at least from my non-native-speaker perspective). – Rev1.0 Apr 15 '16 at 18:16
• English is odd in the sense that, being the default language for global trade, there are probably more non-native speakers than native. So "correct" English becomes that much harder to define. As a native speaker from Kansas City, United States, I had no problems understanding you. – AaronD Apr 16 '16 at 0:38

The main purpose of a bootloader is:

• retrieve program from storage / network and load it.

There can be a very limited amount of fast storage close to the processing unit, and the program that you want to run can be different from board to board or you may want to change the program on your board. The bootloader is a common-denominator program that knows how to load your custom software from where it is stored and feed it to processing unit.

• self tests
• network booting
• ...
• The OP is asking specifically about the bootloaders found in flash-based microcontrollers. While relevant to bootloaders in a more general sense, this answer is wandering a bit off-topic. – Dave Tweed Apr 15 '16 at 15:52

Apart from all the other great answers there is one more reason, at least for commercial products: after production programming most chips have an option set to protect them from reading the data.

Depending one the MCU this read-out protection option can actually disable the hardware programmer connection (like SWD or JTAG). If you do not have the bootloader done, you cannot reprogram the device.

And then you end up with 10k units with buggy software on the market, it incurs a great loss over something which is essentially a few months coding.

It is not the cost of the programmer. The sales do not come from hobbyists; it is a factor but not the factor, folks that buy in volume can certainly afford programmers. You have a few choices:

1. Have the parts pre-programmed either by the parts supplier or a middle man or your manufacturing house, then placed on the board

2. Some sort of in circuit programming after being placed on the board

Within the second category you have the hard logic solutions (the SPI or SPI-ish thing on AVR chips) and the soft solutions (a bootloader, a program running in the part using the part). Some have both.

The hard solution you have to get right, if you goof the design, you have to catch it early enough or your product is a bunch of useless parts you have to trash. You can change software solutions even so far as post silicon; you can even take stock and run it through and re-program it. So there is that luxury if a bug in your product being easier to fix and/or create. The soft solution may also allow for a wider variety of options for the user. SPI AND I²C AND USB AND serial AND whatever hardware solution if any. A soft solution in some cases the user can replace the bootloader with their own for their own reasons.

Not every microcontroller can have software that can program its own flash, but for any that do the user can make their own bootloader independent of the chip vendor supplied one if there is a chip vendor supplied one.

With the ARM Cortex-M and SWD I am seeing things change; some chips are SWD only, and no other from the factory option. I just got an Atmel SAM D21; they no longer have the SAM-BA bootloader and they provide source so you can add your own at the beginning of the user flash, and some registers to sort of protect it, but it is trivial to erase. So much for that; you might as well just make your own or use SWD.

Look at the Arduino/AVR world, the hobbyists. They have their own bootloader and that is the primary interface since it comes for free. You can get an ISP programmer for a few (or few dozen) bucks. But notice how there are a number of other AVR boards going with USB-based protocols instead of the up to that point popular bootloaders. Some of these USB protocols are being used cross vendor.

At the end of the day, if your customers want it and/or your marketing department can use it to distinguish our product from theirs, and it doesn't cut into the cost of the product or profit. Why not? Win-win.

There is no one nor right answer to this question; it is all opinion based. You can contact each of the chip vendors and ask them, but the folks answering are going to give their opinion, they likely don't even know or ever have talked to the folks that added that feature or maintain it. There is no answer to this question.

Just to also give a hobbyist's perspective:

It makes life much easier in not requiring any additional hardware or much low-level knowledge. One extreme example I used was the particle photon (no affiliation) which can get flashed over the cloud. The only things required to flash this chip are:

• Power supply
• WLAN
• Internet connection
• One other computer to write the software

It makes the process rather inexpensive and is actually quite simple from a non-pro perspective.