Upgrading Embedded Design Firmware via USB

By Rakesh Reddy, Cypress Semiconductor Corp.

The ubiquitous USB communication medium that was intended to connect a mice or keyboard to a computer has spawned to
work wonders with speakers, cameras, printers and many other devices. Today, products ranging from guitars to automobiles
come equipped with USB. In such devices, new features can often be added or performance glitches can be fixed through
changes in software running within the embedded controller and using the existing USB connection, designers can exploit an
inherent benefit and provide product resident reprogrammability.

Changing the software running in a microcontroller can often add features and/or fix bugs on a device that were not caught
before shipping. In a glucose meter for instance, compatibility with new strips can be made possible by a change in software.
In the case of an optical mouse that does not work on certain customer’s desks, a software change could allow re-
characterization of data received from the image sensor. Such design changes that do not require a redesign of the hardware
layout are quite commonplace and can be effectively handled by reprogramming the target silicon when the product has not
left the factory. Once in the hands of the customer, however, direct programming is not practical as such processes require
unique hardware and access to dedicated pins on the microcontroller. If the device already required USB to serve as a
communication mechanism, then with the addition of a simple bootloader application in the original firmware, new and
subsequent firmware can be downloaded using a standard computer, either by the manufacturer or an end user.

In embedded microcontrollers, a bootloader is a small program that resides in program memory. When the part is reset or
powered on, the bootloader application runs first and directs the processor to either execute the user application or download
a new one. With this configuration, direct programming is required only to insert the bootloader into the program memory. The
bootloader can then use different communication techniques to fetch the new application. USB, I2C, SPI, UART, or even a
proprietary protocol can be implemented to download the new program. Different approaches can also be used to store the
downloaded application. Based on memory requirements, the program can either be stored on the internal Flash of the
microcontroller or externally in a variety of storage mediums. As most bootloaders can be implemented using a small amount
of program space, they often reside alongside the user application in the same Flash memory. While coexisting, it is the
bootloader application’s responsibility to avoid writing over itself when trying to download code to the same memory. The
bootloader portion of memory space can be write-protected to prevent any accidental corruption.

Upgrading Embedded Design Firmware via USB Page 1 of 5

Published in Embedded.com (http://www.embedded.com) June 2008

[+] Feedback
 Figure 1. USB bootloader data flow

The Bootloader
The general data flow prescribed for a USB bootloader application is shown in Figure 1. Upon power-up or reset, the
bootloader calculates the checksum of the user application and compares it to the one stored in memory set aside as a field
programmable bootloader checksum block. If the two values match, then the bootloader directs the processor to begin
executing the user application. However, if the checksums are different, the bootloader assumes that a host is waiting to
dispatch new user code. In preparation, it turns off any interrupts that could disturb the download process. In certain systems it
might be necessary for the microcontroller to manage critical tasks before starting the download. For instance, a fan might
need to be turned on or some LEDs need to be blinking. As the application space is targeted for deletion, it is important for
critical tasks such as the fan or LED control routines to be a part of the bootloader application.

To begin communication, the bootloader sets up the USB interface and waits till the computer connects with the device. The
handshake process through which a computer learns about what is plugged in is called enumeration. This ensures that the
device is communicating with the right host software, which in this case will be a PC application containing the content that
needs to be downloaded. In order to prevent accidental downloads and to ensure security, the bootloader looks for a key from
the host in the transactions.

Once the key has been verified, the bootloader responds to the host and requests the Flash image. As Flash memory does not
support single address writes, a full page write is required. This is made possible by buffering the arriving data in RAM before
addressing the entire page. As the processor at this point is dedicated to downloading new firmware, almost all the RAM
resources should be available. Writes to Flash need to be stronger at lower temperatures. In order to increase the memory

Upgrading Embedded Design Firmware via USB Page 2 of 5

Published in Embedded.com (http://www.embedded.com) June 2008

[+] Feedback
retention and the number of write cycles, it is important to know the temperature expected in the field and implement the
programming algorithms accordingly. Power stability is also an important factor during flash programming. Any power noise,
glitches, brownouts, slow power ramps, and poor connections can cause problems which are difficult to diagnose. If a power
transient does occur, then the bootloader starts again and restarts the download process as the checksum verification will fail.
Once all the Flash pages including the checksum are successfully written, the bootloader verifies the Flash and initiates a
reset. This time, after system reset, the bootloader finds the right checksum and begins execution of the user code.

Once the valid checksum is in place, any further bootloader operations need to be called from the running user code. With the
right application interface calls in place, the PC application should be able to directly command the user code to disable all
interrupts, reset the USB hardware, and begin functioning as a bootloader. Alternately, the device could be set up to enter the
bootloader enumeration process after being triggered by a change in status of some hardware such as a switch.

Figure 2. Possible layout of a general purpose bootloader

Memory Management
Accidental erasures of the bootloader can cripple any further attempts to download code via USB. A systematic allocation of
memory reduces or eliminates the risk of such a mishap. Figure 2 shows a possible layout that may be employed to arrange
the bootloader application which can be used by a wide variety of Flash architectures. The first set of blocks contains the reset
and USB interrupt vectors. This part of memory is non-relocatable and non-upgradable. The second set, highlighted in green,
comprises the memory that is set aside for the bootloader application. This consists of the initial start command that looks for
the bootloader checksum, the code used for downloading the new image, and finally room for the checksum itself. This set of
code is re-locatable and different sections can be placed in unique areas of memory. However, once the project is ready to be
deployed, all areas of this section except the checksum are non-upgradable.

The third section is set aside for the user application. This portion contains the user code, along with any associated interrupt
vectors and also the routines to call the bootloader application. This area is reprogrammable and re-locatable but should not

Upgrading Embedded Design Firmware via USB Page 3 of 5

Published in Embedded.com (http://www.embedded.com) June 2008

[+] Feedback
be accessed when the bootloader is downloading code. Any interrupts that point to this section of code should be disabled
before calling any bootloader functions. Consider the problems that a program might encounter if the code being executed was
changed during execution.

The PC side of bootloading

On the PC side, a software application needs to communicate with the device and transmit the new user code. This software
can be made available by developers via the web or CD ROMs. The software should be capable of requesting the device to
enter the bootloading state and provide it with the right verification key. When the device is ready, the host should send over
the new contents which will be programmed onto the Flash memory. The user code being downloaded should be stitched
together with the bootloader’s memory allocation in mind. This requires knowledge of the beginning and end of the user code,
the checksum etc. As specified, in normal operation mode, the bootloader will always link to the address where it expects to
find the start of the user code. Any bootloader calls from the user code will also have to point to the correct static locations of
the bootloader functions.

The PC can use a variety of mechanisms to deliver the content over USB to the bootloader. Based on the requirements of the
bootloader residing in the device, either control, interrupt, or bulk transfers can be used to shuttle the data. The USB
descriptors nested in the device can also decide the type of driver support that the application will require. The application can
either be designed to exploit an operating system’s HID driver or use a custom vendor specific one.

Simplifying bootloading
Bootloading is actually a common practice. Personal computers use the same principle for loading an operating system from
a hard-drive. Many reference designs and example projects on the web help with the implementation of a bootloader in
embedded designs. For example, Cypress Semiconductor’s PSoC Designer is an utility that can be used to create a USB or
I2C bootloader that works with a wide series of Programmable System on Chips or PSoCs™. The USB bootloader user
module generates all required bootloader code in a framework that coexists with the user application. This utility allows design
of either a full speed, chapter 9 compliant, HID, or generic USB device. A wizard that helps generate accurate USB descriptors
and supports bootloader transfers using either interrupt or control transfer types.

Figure 3: The USB bootloader looks for various selectable parameters such as the location of the first and last user
application blocks, the first and last bootloader blocks, and the checksum addresses.

The user module dynamically creates the bootloader code based on the requirements anticipated during the design process.
As shown in Figure 3 it looks for various selectable parameters such as the location of the first and last user application

Upgrading Embedded Design Firmware via USB Page 4 of 5

Published in Embedded.com (http://www.embedded.com) June 2008

[+] Feedback
blocks, the first and last bootloader blocks, and the checksum addresses. Bootloader size can be also be customized to allow
insertion of any special code that needs to run alongside the download process. The key that is prepended to USB
transactions is also customizable. Knowledge of the anticipated temperature during future bootloader operations allows the
utility to generate the appropriate programming routines. Finally, users can generate functions like void
BootLdrUSB_EnterBootloader(void) that provide user code with ability to initiate bootloading operations from within the
application.

The module generates and validates the checksum of the content that is to be downloaded through the bootloader. Another
tool derives the download file from the output of the compiler. This *.dld file contains the hex code arranged in Flash blocks
along with the new checksum. It can be parsed easily by PC applications written using Visual Basic or C#.

Engineering a method to download new user application into devices via USB can allow end users to upgrade their products
for bug fixes or feature enhancements. The ability to update without requiring any special hardware eliminates the need for
expensive recalls or replacements.

Cypress Semiconductor
198 Champion Court
San Jose, CA 95134-1709
Phone: 408-943-2600
Fax: 408-943-4730
http://www.cypress.com

© Cypress Semiconductor Corporation, 2007. The information contained herein is subject to change without notice. Cypress Semiconductor Corporation assumes no responsibility for the
use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any license under patent or other rights. Cypress products are not warranted nor intended
to be used for medical, life support, life saving, critical control or safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize
its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of
Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges.

PSoC Designer™, Programmable System-on-Chip™, and PSoC Express™ are trademarks and PSoC® is a registered trademark of Cypress Semiconductor Corp. All other trademarks or
registered trademarks referenced herein are property of the respective corporations.

This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide patent protection (United States and
foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a personal, non-exclusive, non-transferable license to copy, use, modify, create
derivative works of, and compile the Cypress Source Code and derivative works for the sole purpose of creating custom software and or firmware in support of licensee product to be used
only in conjunction with a Cypress integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source Code
except as specified above is prohibited without the express written permission of Cypress.

Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the right to make changes without further notice to the materials described
herein. Cypress does not assume any liability arising out of the application or use of any product or circuit described herein. Cypress does not authorize its products for use as critical
components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support
systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges.

Use may be limited by and subject to the applicable Cypress software license agreement.

Upgrading Embedded Design Firmware via USB Page 5 of 5

Published in Embedded.com (http://www.embedded.com) June 2008

[+] Feedback