by Shawn Prestridge, IAR Systems

Constructing a bootloader
Please note that this article describes how to create a bootloader for an ARM target, using IAR Embedded Workbench for ARM. The steps involved may differ for other targets.

As software becomes more and more complex, the potential for defects to exist in shipped code increases exponentially. It is therefore becoming quite common for design specifications to call for the ability to dynamically update a devices firmware in the field. This is done commonly via a bootloader. In this article, we will discuss some of the issues involved with developing a bootloader and show you how to set one up with IAR Embedded Workbench. The pragmatics of designing a bootloader are somewhat difficult to discuss because there can be so many different requirements placed on it, e.g. the mechanism for getting the new application into the MCU; for some, it will be through the USB peripheral of the MCU, for others, it might be through the Ethernet peripheral and TCP/IP and still others might choose to do it through the venerable RS232 port. Because a bootloader is a very common thing to do, it is highly advisable that you check with your silicon providers Field Applications Engineer to see if they have already created a sample bootloader project for your MCU which can greatly simplify your construction of a bootloader to fit your needs. In the IAR Embedded Workbench hierarchy for project management, the workspace is the top-level entity and is what opens when you start the tool suite. Workspaces can have multiple projects contained within them; for this article, I have attached a workspace with two projectsa main application project as well as a bootloader project. Within the workspace, we can control in what order the projects are built. For our purposes, we want the application to be built first and then the bootloader; this is because we will place the application image in the bootloader when the bootloader is built. This can be done using the Batch build facility available from the IAR Embedded Workbench IDE by clicking Project-BatchBuild. You can edit the batch to add projects to the build as well as rearrange them in the order that you would like for them to be built. There are compelling reasons to NOT place your bootloader and application in the same project. First, IAR Embedded Workbench will generate a massive binary (especially if the bootloader and application start addresses are far apart). If there are peripheral addresses between the end of the bootcode and the start of the application code, you may experience flashloader failures when they try to write blank bytes to those addresses, thus necessitating a rewrite of the flashloader. Even if this isnt the case, a bootloader will most likely have a statically allocated array for code reception that will waste space when the application is running. By having them as two separate applications, the linker can more efficiently allocate memory. Yet another compelling reason is that you cannot independently revise your bootloader or applicationif they are in the same project, touching one automatically means touching the other and can therefore lengthen the test-and-fix cycle for your project. As previously stated, we want to allocate space for the bootloader and then place the application in the unused space. For this example, the idea is to set up the linker so that all of the code for the main application project is placed above a certain address (0x2000 in this case) and all of the bootloader code is placed below that address. Once this is done, it is possible to produce a binary image of the main application project; the advantage of doing so is that you can import the binary image of the main application into the bootloader project which will allow you to download the bootloader and main application all at once with the debugger. To summarize, we do the following:

Page 2

Application: 1. Create a project for the main application. 2. Set up the linker to place all the code (and constant data) between the start of the space reserved for the application and the end of memory. 3. Set the output converter (Project-Options-OutputConverter-Output) to create a binary file. The binary file is simply the content of the memory, i.e. there is no formatting or address information of any kind. Bootloader: 1. Create a project for the bootloader. 2. Set up the linker to place all of the code and constant data between 0 and the end of the space reserved for the bootloader (0x1FFF in this case). 3. Set up the linker to import the binary file created in part 1 above; this is done from ProjectOptions-Linker-Input. The linker will treat the binary image as though it were a constant array and simply copy its contents to the address specified in the linker configuration file. The linker must be given a symbol name for this image as well as in which section to place this image and the number of bytes to on which to align the image. The linker must also be told to keep this symbol in case the symbol is not referred to in the bootloaderany symbol not specifically referred to by an application will normally be removed. In the attached example, I have chosen to make the symbol name application, the section name .app and the alignment 4 bytes. 4. Set up the linker to place the section .app at the desired location. To accomplish this, I have defined two memory regions called BOOTROM_region and APPROM_region in the attached flash_bootloader.icf. The binary image is placed in APPROM_region and everything else goes in BOOTROM_region. Debugging To download the main application without erasing the bootloader, you must configure the flashloader. The flashloader is a small piece of code downloaded through the JTAG into RAM and is what takes the application code from the JTAG and programs your code into the flash of your device (or perhaps into an external flash part on your board). We must modify the flashloader to program only a certain range so that we dont overwrite the previously written bootloader (or viceversa). By looking in the applications Project-Options-Debugger-Download, you will see that the Use flashloader(s) and Override default .board file options are checked. To change the range over which the flashloader operates, click the Edit button, then select the flashloader and click Edit once more. In the flashloader configuration dialog box, you will see the memory range box for the flashloaderset this range to exclude the part you do not wish to erase. In general, debugging a bootloader can be a bit tricky since you will only have source-level access to either the bootloader or the application at debug-time. It may be useful to implement a well-crafted delay loop in the startup of the application to allow you time to halt source-level debugging of the bootloader and begin source-level debugging of the application. In your application, choose ProjectOptions-Debugger-Download and click the box for Attach to programnotice that this deselects the Use flash loader(s) box. Attach to program allows you to non-intrusively attach to a running board without halting or resetting it. Once you have selected Attach to program, click OK and then click Debug without downloading to attach to the board. You can now press the Halt button in the debug toolbar to see where you are in the delay loop, set breakpoints or whatever you need to do to debug the application. To summarize the debugging: 1. 2. 3. 4. 5. Insert a delay loop of 1015 seconds in the startup routine of the application. Modify Project-Options-Debugger-Download in the application project settings to Attach to program. Batch build in the order of the application first, then the bootloader. Download/debug the bootloader (which also downloads a binary image of the application). Debug your bootloaderwhen it hands off execution to the application, exit the debugger to allow the delay loop to execute.

Page 3

6. 7. 8.

Switch to the application project and click Debug without downloading to attach to the board. Halt the board to see where you are in the delay loop and/or set breakpoints. Debug your application!

Creating a bootloader can be somewhat tricky, but with these tips and tricks you should be well on your way to creating a successful dynamic software update mechanism.