下载
Analog Dialogue 52-11, November 2018
1
Radio
ADF7242
Sensor
ADXL362
Micro-
controller
ADuCM3029/
ADuCM4050
Processor
ServerClient
Radio
Figure 1. Server/client architecture in an example embedded system.
What Makes a Software Application?
Much of the OTA update process is the act of transferring the new software
from the server to the client. The software is transferred as a sequence
of bytes, after it has been converted into a binary format from the source
format. The conversion process compiles the source code files (for example,
c, cpp), links them together into an executable file (for example, exe, elf), and
then the executable is converted into a portable binary file format (for exam-
ple, bin, hex). At a high level, these file formats contain a sequence of bytes
that belong at a specific address of memory in the microcontroller. Typically,
we conceptualize the information being sent over a wireless link as data,
such as a command to change the system’s state or sensor data collected
by the system. In the case of the OTA update, the data is the new software
in binary format. In many cases, the binary file will be too large to send in a
single transfer from the server to the client, meaning that the binary file will
need to be placed into separate packets, in a process called packetizing. To
visualize this process better, Figure 2 demonstrates how different versions of
the software will produce different binary files, and thus different packets to
be sent during the OTA update. In this simple example, each packet contains
8 bytes of data, with the first 4 bytes representing the address in the client’s
memory to store the next 4 bytes.
Major Challenges
Based on this high level description of the OTA update process, three
major challenges arise that the OTA update solution must address. The
first challenge relates to memory. The software solution must organize the
new software application into volatile or nonvolatile memory of the client
device so that it can be executed when the update process completes.
The solution must ensure that a previous version of the software is kept
as a fallback application in case the new software has problems. Also, we
must retain the state of the client device between resets and power cycles,
such as the version of the software we are currently running, and where
analogdialogue.com
Abstract
Many embedded systems are deployed in places that are difficult or
impractical for a human operator to access. This is especially true for
Internet of Things (IoT) applications, which are typically deployed in larger
quantities and with limited battery life. Some examples would be embed-
ded systems that monitor the health of a person or a machine. These
challenges, coupled with the rapid software lifecycle, cause many systems
to require support for over-the-air (OTA) updates. An OTA update replaces
the software on the microcontroller or microprocessor of the embedded
system with new software. While many people are very familiar with OTA
updates on their mobile devices, the design and implementation on a
resource constrained system leads to many different challenges. In this
article, we will describe several different software designs for OTA updates
and discuss their trade-offs. We will see how hardware features of two
ultra low power microcontrollers can be leveraged in OTA update software.
Building Blocks
Server and Client
An OTA update replaces the current software on a device with new soft-
ware, with the new software being downloaded wirelessly. In an embedded
system, the device that runs this software is typically a microcontroller. A
microcontroller is a small computing device with limited memory, speed,
and power consumption. A microcontroller typically contains a micropro-
cessor (core) as well as digital hardware blocks for specific operations
(peripherals). Ultra low power microcontrollers that typically consume
30 μA/MHz to 40 μA/MHz in active mode are ideal for this type of appli-
cation. Using specific hardware peripherals on these microcontrollers and
placing them into low power modes is an important part of the OTA update
software design. An example of an embedded system that might require
OTA updates is shown in Figure 1. Here we see a microcontroller con-
nected with a radio and sensor, which may be used in an IoT application
that gathers data about the environment using the sensor and reports it
periodically using the radio. This portion of the system is referred to as the
edge node or client and is the target of the OTA update. The other portion
of the system is referred to as the cloud or server and is the provider of the
new software. The server and client communicate over a wireless connec-
tion using transceivers (radios).
Over-the-Air (OTA) Updates in Embedded
Microcontroller Applications: Design Trade-
Os and Lessons Learned
By Benjamin Bucklin Brown
Share on
@0000_0000
00 20 00 20 0B 1A 00 00
@0000_0200
70 B5 04 46 1E 00 08 46
Build
Packet 0
{00, 00, 00, 00, 00, 20, 00, 20}:
Packet 1:
{04, 00, 00, 00, 0B, 1A, 00, 00}
Packetize
int main(void) {
run_my_application();
return 0;
}
Figure 2. Binary conversion and packetization process of a software application.
