1.2 Overview

A bootloader is used when the user or manufacture wants a way to update their device in the field with a new application. To do this, the device in the field needs some type of connection between the device to update and a PC or other device which has the new application firmware. This implies that the device in the field must contain not only the application, but some way of using this interface to update the application firmware. While its possible for each application to write there own method to do this, writing firmware to update the firmware on a device is a non-trivial process and usually requires a deep understanding of the device operation, the software compiler and linkers and the update SW running on the updating device like a PC. Because of this steep and broad learning curve, companies like Microchip provide the basic bootloader infrastructure for their devices.

The bootloader infrastructure has three main components: The bootloader, the application and the external host used to transfer the new application to the device. The bootloader is firmware that first runs when the device comes out of reset. It verifies that the application on the device is valid before running the application. The bootloader may also check for a signal to update the firmware. This could be as simple as checking the value of a GPIO pin or checking for a specific type of traffic on the UART indicating that there is new application firmware to needs to be installed. The application is the second part of the infrastructure. Finally, a method to transfer the new application firmware from an external PC or device to the targeted device. This could be over a UART, USB, SPI or other port.

The bootloader discussed above is the low-level code that runs when the device comes out of reset. Its main purpose is to check to see if there is a new application that needs to be installed on the device, and if there is, provide a path to accomplish this. Another important feature of bootloaders that many people use is the verification of the application before transferring control to the application. This is usually done by computing the checksum of the application and comparing the computed checksum against the expected checksum. If they don't match, the firmware has been corrupted somehow and the bootloader will not load the application. The bootloader that the MCC generates has 3 main components: the Bootloader Core, the Comm Adapter and the infrastructure for the user application. The Bootloader Core is located in boot_process.c. It is responsible for interacting with the communication adapter looking for commands, then upon receiving a command, parsing it and executing it. If the command involves interfacing with the flash, it will work with the flash driver to read or write the flash contents. The purpose of the communication adapter is to provide a consistent interface for the bootloader to communicate to any interface. it uses four functions to interface with any communication device. In this example, it's the UART communication adapter located in the file com_adaptor_uart.c.