Posted on : Sat , 11 2014 by : virusi
Theory on Bootloader :
What is a boot-loader ?
A boot-loader is an application whose primary purpose is to allow a systems software to be updated without the use of specialized hardware such as a JTAG programmer. The boot-loader allows a company to launch their product with software that only fulfills a portion of their final feature set and then add features to their product once it has been launched into the market.
How it works ?
The boot-loader receives new program information externally via some communication means and writes that information to the program memory of the processor. They can communicate over a variety of protocols such as USART, CAN, I2C, Ethernet, USB and the list goes on for as many protocols that exist. There are two behavioral models that describe how a boot-loader can behave :
– automated boot-loading . The boot-loader would automatically detect the new firmware and manage its own flashing process. Commands from an external source would not be required to successfully carry out the boot-loading process.
– manual boot-loading. The boot-loader initializes into an idle state and awaits instructions from an outside source. This source would typically be a pc based software application that commands the boot-loader into the different states necessary to flash a new image onto the system.
Each boot-loader will be unique in the number and type of commands that are supported. A sophisticated boot-loader will have more commands than a simple boot-loader. Flash usage for the boot-loader increases with each command that is supported potentially resulting in less space for the application image. At a minimum the boot-loader should support three commands.
– Erase the flash. Removal of the application image from memory.
– Write flash. Addition of a new application image to memory.
– Exit / Restart–reboot with the intention of entering the application code.
With these three commands all basic functions of writing an image to flash can be accomplished. Now let’s take a look at some examples where boot-loader can reside in the microcontroller memory.
As you can see from the Fig.1 the tool chain will place the application code at the start address of the flash memory (depending on the processor the start address of the flash memory ca can be at address 0) and the entire flash can be used by the application.
In this example the boot-loader is placed in ROM and the application can use the full flash. The application is placed at start address of the flash memory. This option protects the boot-loader from being mistakenly overwritten but the downside of this method is that if you need to update the boot-loader this will be impossible.
Boot-loader challenges ?
A boot-loader should be able to detect, report, and handle errors that occur during the boot-load operation, such as power failure, loss of communication, and Flash write error. Flash error protection is usually done by storing a checksum or Cyclic Redundancy Code (CRC) for the application. If the new application is downloaded and installed successfully, the checksum is updated. If, however, an error occurs during download (such as loss of communication or power failure), the boot-loader detects invalid check bits and does not begin application operation. Instead, it communicates with the host and waits for a valid retry of the boot-load operation. Another key consideration is to prevent code from overwriting the boot-loader area itself. If a boot-loader attempts to, or accidently does, overwrite itself and an error event occurs, the boot-loader can be left inoperable.