Making Embedded Systems

Chapter 7. Updating Code

When your system has problems after it goes out into the wild, you’ll need to be able to update the code on a device in the field. To understand the complexities, let’s start by looking at how uploading works in the comfort of your development lab, and how that differs from uploading to a device you’ve released.

During development, your system lets you peer into the guts of the code, maybe with a JTAG that can stop the processor. As part of the process, you also get to modify the code (aka flashing the chip). The method for doing that is chip-dependent, but it usually requires some special debugging widget. If you want to update the code after the system leaves your desk, you’ll need to plan ahead. Although we’d like to arm the world with development hardware, it isn’t cost effective (sadly).

The lowest level of updating code is very chip-dependent, but the general procedure follows certain common patterns.

Tip

There are many different names for updating code on a device: bootstrap loading, bootloading (even when it isn’t related to booting), updating, uploading, burning the code, and over-the-air programming. Whatever you call it, uploading code is one of the most difficult topics in embedded systems. It is right up there with storing code on cartridges, keeping consumables secure, and faking floating-point math via binary scaling. This chapter may be tough the first time you read it. Don’t lose hope.

Three different loaders are described in ...