Bootloaders 101: making your embedded design future proof
Either way, the result will require a reprogram of the entire system.
Reprogramming typically requires a qualified technician with development
tools in hand to plug into the board. This tends to defeat the appeal
of the bootloader. Proper control over device memory locations is
critical when developing a bootloader. Special care must be taken to
ensure memory locations are managed and changes to application size do
not improperly erase or rewrite bootloader memory. To prevent potential
rewrite problems, some microcontrollers even put the bootloader in a
hard-coded bootload read-only memory (ROM) that is separate from Flash,
as shown in Figure 3.
Figure 3 shows four memory space examples. The left-most graphic is a normal non-bootloader application program. The typical tool chain will place the application code at address 0 and the entire Flash memory array is eligible to be used for application code space. If this type of system is put into the field as a released product, it cannot be remotely modified. Upon reset the application code begins to execute. Any bugs or defects in the application code are permanent.
In the left center is an example of a bootloader with bootloadable image in ROM. This configuration allows for the full Flash space to be used for the application because the bootloader resides in separate ROM memory. This option protects the bootloader from being mistakenly overwritten, but if the bootloader needs to be updated, it will not be impossible. ROM is written once and cannot be reprogrammed or fixed if a defect is discovered.
In the right-center graphic, the bootloader is shown located at address 0 and executes first out of reset. Once the bootloader has determined that the bootloadable image is valid and there are no commands from the host to re-image the part, the bootloader will turn over control to the bootloadable application. You can see how the bootloadable image starts just after the bootloader image ends. This maximizes the quantity of memory available for use by the bootloadable image. The last image shows two sections of memory used for two different bootload events.
In this case, the bootloader may decide which application will be run under different bootup operations as directed by the host. This approach consumes double the Flash space as it requires holding two complete application programs, but it is quite an efficient design methodology if engineers desire to have single device operate differently under different host-directed conditions.
The most obvious benefit of a bootloader is the ability to fix errors in the field. Products can also benefit from feature updates. For example, customers have been known to launch products that are designed with basic functionality to get to market faster only to later release a bootloadable update to change OS drivers, product features, update power management options, etc.
Bootloaders allow design teams to get to market with a future roadmap of hardware updates. For example, some companies use a radio link for communications to provide remote monitoring of equipment. These companies have found it more cost-effective to deploy updates to equipment over the radio link compared to having a technician visit a remote site to update firmware.
Consider the case of fleet management in the trucking industry. Taking a vehicle out of service for something as minor as a code update or enhancement is expensive. Just the shop time for code upgrades can run into the hundreds of dollars. Remote bootloading can provide tremendous value for fielded products.
So what makes a bootloader a good bootloader? While there are many answers to this question, one of the principle requirements is ease of use. Making a bootloader that allows designers to easily choose and connect to a serial communication port is critical. Additionally, providing a convenient method to get into the bootloader or to bypass the bootloader and directly access the application are important as well.
Once created, the bootloadable image becomes dependent on the bootloader. Having to determine where the bootloader image ends and the application can begin is also tedious and prone to error. A good bootloader should handle these issues automatically and will also give the designer the flexibility to use multiple application images. These dual bootloadable systems are sometimes referred to as multi-application bootloaders. This type of bootloader will load the new image to a separate area in memory. Once validated, the bootloader will either copy that image over the existing application or just switch over to that image for execution.
Consider the way this is accomplished in the bootloader used in the PSoC3 and PSoC5LP families of products. As shown in Figure 4, the communication component is selected via a dropdown menu. A time to “Wait for command” to enter the bootloader (2s in this example) can be configured to a set time. Allowing the designer to select from checksum types is also convenient.
On the bootloadable side, it is nice to have numerical revision identification. This allows the firmware to automatically determine if a new bootloadable image is out of date. The image in Figure 4 shows how designers have the flexibility to specify the application version and ID. In addition, designers have the ability to manually move the application image to a desired memory address.
Finally, one of the key issues noted above is the risk of memory overwrite. The tool chain in the bootloader used in the PSoC3 and PSoC5LP families of products automatically locates the end of the bootloader and the beginning of application address to remove this risk. Since the entire point of using a bootloader is to strategically eliminate risk, this is a great feature to employ.
So, if all or your projects are on time, all of your code is perfect, and all your firmware engineers are code-complete before hardware must be built, then you really have no use for a bootloader. If you are like the rest of the world, there are substantial benefits for implementing a bootloader in any embedded system your organization develops.
Bootloaders allow a product to be updated after launch for any number of reasons ranging from catastrophic bug fixes to planned product feature upgrades. The key issues while bootloading, however, concern the flexibility and ease of the bootloader itself as well as the code space and configuration used for the bootloader. But in the end, a well designed bootloader just might save your product, just might save your team, and just might save your sanity.
David Durlin is a Principle Field Applications Engineer at Cypress. He has been in this position for 6 years. Prior to Cypress David was a FAE for Future Electronics. The first six years out of University David gained experience in design of instrumentation and lighting in heavy equipment. David also designed microcontrollers at Zilog.
David’s hobbies when not at work are making beer, designing and programming home automation projects.
David received his undergraduate degree in Electrical Engineering from University of Idaho.
Now living in Washington and can be contacted via email at email@example.com.
Trevor Davis is a Cypress veteran who has worked within several different product groups at Cypress. He has most recently led the World Wide Business Development organization for Cypress’s TrueTouch products and is now the Regional Sales Manager for the Rocky Mountain region in the USA. Before TrueTouch, Trevor served in several different Product Marketing and Business Development leadership roles for Cypress Programmable System on Chip (PSOC), USB products, Network Search Engines, CPLDs, and Software products.
Trevor received his undergraduate degree from the United States Air Force Academy and also holds his Masters in Business Administration. Trevor has worked in high technology positions for the military, nonprofit, and commercial sectors. Trevor lives in Seattle, WA and can be reached at firstname.lastname@example.org