Arduino’s Bootloader

What is the concept of the bootloader?

The concept of a bootloader is similar to the concept of a Track Crane.

Picture this scenario: All the tools needed to load the main code are already present inside the chip. A type of a heavy-duty machines that are typically used for hoisting various loads.

The bootloader is a means to get your software programmed into the microcontroller.

Usually the main reason for use a bootloader is to be able to program the microcotroller without an external programmer.

This is in contrast with the normal way of getting the program into the microcontroller, which is via special hardware built into the micro for that purpose. On ARDUINO’s, this is a SPI-like interface.

The Serial Peripheral Interface Bus (SPI) interface is used for communication between multiple devices over short distances, and at high speed.

Typically there is a single master device, which initiates communications and supplies the clock which controls the data transfer rate. This requires some external hardware that wiggles the programming pins just right to write the information into the program memory. The HEX file describing the program memory contents originates on a general purpose computer, so this hardware connects to the computer on one side and the special programming pins of the micro on the other.

Mainly the bootloader have to perform a minimally :

1. initialize the controller peripherals;
2. get the application (UART — SD card …etc );
3. load selected user application;
4. start the code (execute);

Some Bootloaders can perform many other functions . The Bootloader codes in microcontrollers are actually very small and simple compared to the Bootloaders in advanced devices like PC.

Bootloaders for 8-bit microcontrollers tend to be very simple.

The common method to program a microcontroller is to use a programmer for that particular microcontroller. An alternative is to write a small program (a bootloader) into the flash memory of the microcontroller which allows code and EEPROM data to be transmitted over a serial cable and written to the microcontroller.

Possible Implementations

There are several ways to implement a bootloader. Let’s raise some hypotheses based on Olin Lathrop’s work:

Basic bootloader: This device had a serial line and would be connected to a host and turned on as needed. The bootloader ran from reset and sent a few upload request responses to the host. If the upload program was running, it would respond and send a New Program Image. If it didn’t respond within 500 ms, the bootloader would give up and run the Existing App. To update firmware therefore, you had to run the Updater App on the host first, then connect and power on the device;

This is exactly the approach the Arduino team has come up with.

Program memory uploader: Here we used the next size up MCU that had twice as much program memory. The program memory was roughly divided into 49% Main App, 49% New App Image, and 2% bootloader. The bootloader would run from reset and copy the new App Image onto the Current app Image under the right conditions;

External EEPROM image: Like #2 except that a external EEPROM was used to store the New App Image. In this case the processor with more memory would have also been physically bigger and in a different sub-family that didn’t have the mix of peripherals we needed;

TCP/UDP bootloader: This was the most complex of them all. A large MCU was used. The last 1/4 of memory or so held the bootloader, which had its own complete copy of a TCP network stack. The bootloader ran from reset and tried to connect to a special upload server at a known port at a previously configured IP address. This was for large installations where there was always a dedicated server machine for the whole system. Each small device would check in with the upload server after reset and would be given a new app copy as appropriate. The bootloader would overwrite the existing app with the new copy, but only run it if the checksum checked. If not, it would go back to the upload server and try again;

OTA (Over the Air): update is the process of loading the firmware to ESP module using Wi-Fi connection rather than a serial port. Such functionality became extremely useful in case of limited or no physical access to the module.

Notes about Bootloader

1. A bootloader has to written to the flash memory just once using a conventional programmer; The bootloader is programmed such that when bootloader start condition is satisfied it receives data via a predeterming addresses;
2. A bootloader is a program that runs in the microcontroller to be programmed. It receives new program information externally via some communication means and writes that information to the program memory of the processor;
3. The bootloader appears at the CPU’s designated starting address (zero, most likely); It loads the program into the required memory segment;It transfers control to it, and disappears;The appearance and disappearance are controlled by external hardware;
4. No two bootloader are the same. There is no general purpose bootloader, despite what some of the microcontroller companies want you to believe;
5. The important point of external programming via specialized hardware is that it works regardless of the existing contents of program memory. Microcontrollers start out with program memory erased or in a unknown state, so external programming is the only means to get the first program into a micro;
6. All AVRs except the Xmega family (which has a new 2-wire interface) use an SPI interface while kept in reset. Larger ones also have JTAG, some have parallel programming, and smaller ones may require high voltage if reset has been reconfigured as I/O. Some MCUs, like the Parallax Propeller and Motorola/Freescale 68HC08 families, have no to minimal programming hardware but bootloaders in ROM;
7. Depending on what you want out of one or the system they’re designed for, you can design one to upload stuff to a specified location in RAM instead of FLASH, and begin execution at any arbitrary memory location. Or maybe you want one that is capable of choosing which operating system to load when your PC boots (see grub for example).
8. Bootloaders for 8-bit microcontrollers tend to be very simple;
9. If it is a completely blank chip with no existing bootloader that can update itself, then you would need to burn to FLASH much like you described using whatever technique is required to accomplish that (ICSP in the case of AVR);
10. If you are sure about the program you want to load into your product and your volumes are high enough, you can have the manufacturer or a distributor program chips for you. The chip gets soldered to the board like any other chip, and the unit is ready to go. This can be appropriate for something like a toy, for example. Once the firmware is done, it’s pretty much done, and it will be produced in large volumes;
11. If your volumes are lower, or more importantly, you expect ongoing firmware development and bug fixes, you don’t want to buy pre-programmed chips. In this case blank chips are mounted on the board and the firmware has to get loaded onto the chip as part of the production process. In that case the hardware programming lines have to be made available somehow. This can be via a explicit connector, or pogo pin pads if you’re willing to create a production test fixture. Often such products have to be tested and maybe calibrated anyway, so the additional cost of writing the program to the processor is usually minimal. Sometimes when small processors are used a special production test firmware is first loaded into the processor. This is used to facilitate testing and calibrating the unit, then the real firmware is loaded after the hardware is known to be good. In this case there are some circuit design considerations to allow access to the programming lines sufficiently for the programming process to work but to also not inconvenience the circuit too much. For more details on this, see  Olin Lathrop from Embed Inc in-circuit programming writeup;
12. If power fails in the middle of copying the new version onto the current, then the current version checksum will fail when power comes back and the bootloader runs again. Programmers usually put the checksum word at the very end of the image so that any partial write has a very good chance of checksum failure. — ootloader;
13. Fail safe inssue: If a new app image is not received intact, you want the device to continue on running the old image, not to be dead until a successful upload is performed. For this reason, usually there are actually two special modules in the firmware, a uploader and a bootloader.
14. If your product already has a communications port that can easily interface with a PC, like USB, RS-232, or ethernet. The customer runs a PC program which talks to the bootloader already in the micro. This sends the new binary to the bootloader, which writes it to program memory and then causes the new code to be run;

Hopefully you can see that there are a number of other possibilities, each with its own tradeoffs of risk, speed, cost, ease of use, downtime, etc.

In future posts I intend to implement a simple bootloader in ATtiny85. If you already know how to do this, please comment here ;)

References & Credits

http://www.embedinc.com/olin/

What is a boot loader, and how would I develop one?

http://esp8266.github.io/Arduino/versions/2.0.0/doc/ota_updates/ota_updates.html