AN3262
Application note
Using the over-the-air bootloader with STM32W108 devices
1
Introduction
This document describes the over-the-air bootloader provided for STM32W108 devices. The
over-the-air (OTA) bootloader is a modified version of the USART-based bootloader
specified in application note AN3155 in order to deal with an 802.15.4 wireless
communication channel rather than a USART cable.
For more information, please refer to application note AN3155
USART protocol used in the
STM32 bootloader
available from www.st.com/stm32w.
This document applies to the following STM32W108xx kits:
●
●
●
STM32W108xx starter kit (part number: STM32W-SK)
STM32W108xx extension kit (part number: STM32W-EXT)
STM32W108xx low-cost RF control kit (part number: STM32W-RFCKIT).
Overview
The purpose of the OTA bootloader application is to enable any node to receive a firmware
image over the air using the 802.15.4 interface and write it in Flash memory. In this context,
nodes willing to update their Flash contents with the new image are referred as bootloader
device nodes, while those in charge of transmitting the image over the air will be called
bootloader host nodes.
Figure 1.
Memory layout
Total of 128 Kbytes
Application (Up to 116 Kbytes)
OTA Bootloader (12 Kbytes)
Figure 1
shows the memory layout of a bootloader device node; in order to be defined as
such it needs an OTA bootloader application image loaded right from the beginning at the
base of the STM32W Flash area (0x08000000) and any user application to run on the node
will have to sit on the top of the OTA bootloader. The bootloader takes 12 Kbytes leaving up
to 116 Kbytes free for user applications. At chip reset, control is passed to the bootloader
which in turn jumps to the application if present in Flash memory, or else it will just remain in
its main loop waiting for valid image packets sent by a host from the 802.15.4 RF interface. It
is also possible to override the default ‘jump to application’ behavior by forcing a bootloader
startup using a user-defined action (for example, a button press after reset). The bootloader
can eventually be started up from the application as well, but it depends on the application;
details related to bootloader activation criteria are out of the scope of the bootloader code.
March 2011
Doc ID 17845 Rev 2
1/27
www.st.com
Contents
AN3262
Contents
1
2
3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Communication protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Bootloader command set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
Get command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Get Version & Read Protection Status command . . . . . . . . . . . . . . . . . . . 8
Get ID command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Read Memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Go command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Write Memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Erase Memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Write Incremental Memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2/27
Doc ID 17845 Rev 2
AN3262
Communication protocol
2
Communication protocol
A bootloading session consists of exchanges of commands codes and related data between
bootloader device (target) and host (transmitter) nodes. The protocol chosen for this
purpose is the same one as specified in application note AN3155 for STM32 USART
bootloader; its commands are a subset of those specified. The command set is further
described in the next section. The replacement of USART (universal
synchronous/asynchronous receiver/transmitter) with the 802.15.4 standard for point-to-
point transmission of bits over the air, implies the deployment of all the well-known features
to cope with lossy channels such as CRC check, MAC level ACK detection and packet
retries in addition to all the functions that the (higher level) protocol provides to improve the
reliability of communication as described in the next section.
Commands and data are sent in the 802.15.4 payload which is variable in size according to
the specific information to be sent. 802.15.4 packets can be sent unicast and broadcast.
Broadcast packet are supported by a subset of commands and they are useful to discover
nodes in bootloader mode.
Figure 2
shows the selected format for a unicast 802.15.4 packet.
Figure 2.
Frame
Control
(2 bytes)
0x61 0xCC
802.15.4 packet format for unicast packet transmission
Sequence
Number
(1 byte)
Destination
Pan ID
(2 bytes)
Destination
EUI64
(8 bytes)
Source
EUI64
(8 bytes)
Payload
(variable)
FCS
(2 bytes)
Figure 3
shows the selected format for a broadcast 802.15.4 packet.
Figure 3.
Frame
Control
(2 bytes)
0x01 0xC8
802.15.4 packet format for broadcast packet transmission
Sequence
Number
(1 byte)
Destination
Pan ID
(2 bytes)
0xFFFF
Destination
Short
Address
(2 bytes)
0xFFFF
Source
EUI64
(8 bytes)
Payload
(variable)
FCS
(2 bytes)
The communication channel (between channels 11 and 26) and the PAN ID can be freely
chosen by the application before it launches the bootloader. In the case, where the
bootloader is not started by the application, it will run on a default channel (15) and default
bootloader PAN ID 0xB00B.
Doc ID 17845 Rev 2
3/27
Bootloader command set
AN3262
3
Bootloader command set
Table 1
lists commands supported by the OTA bootloader. A detailed command-by-
command protocol description follows.
Table 1.
OTA bootloader commands
Command code
0x00
0x01
0x02
0x43
0x31
0x36
Command description
Gets version number and list of commands allowed.
Gets bootloader version and Read Protection status of
the Flash memory.
Gets chip ID of device.
Erases memory pages of selected device.
Writes up to 96 bytes in memory of selected device.
Writes up to 96 bytes in memory of selected device
incrementing next write address on device
automatically.
Reads up to 96 bytes of memory starting from a user-
specified address.
Starts the code at a given location for a given device.
Command
G
ET (1)
G
ET
V
ERSION (1)
G
ET
ID
(1)
E
RASE
W
RITE
M
EMORY
W
RITE
I
NCREMENTAL
M
EMORY (2)
R
EAD
M
EMORY
G
O
0x11
0x21
1. This command is supported by unicast and broadcast packets, while all the other are unicast only.
2. The W
RITE
I
NCREMENTAL
M
EMORY
command is the only one not included in the original USART bootloader
command set.
Communication safety
All communications from the Host to the device are verified by:
●
Checksum: received blocks of data bytes are XORed. A byte containing the computed
XOR of all previous bytes is added to the end of each communication (checksum byte).
By XORing all received bytes, data + checksum, the result at the end of the packet
must be 0x00.
For each command, the host sends a byte and its complement (XOR = 0x00).
ACK = 0x79
NACK = 0x1F
●
Each packet is either accepted (ACK) or discarded (NACK):
●
●
4/27
Doc ID 17845 Rev 2
AN3262
Bootloader command set
3.1
G
ET
command
The G
ET
command is used to determine the version of the bootloader and the supported
commands. When the bootloader receives the G
ET
command, it transmits the bootloader
version and the supported command codes to the host as shown in the figures below.
Figure 4.
G
ET
command (host side)
Start
Get
Send
0x00 + 0xFF
Wait for ACK
or NACK
ACK
NACK
Receive the number of
bytes
(version+commands)
Receive the
bootloader
version
Receive the
supported
commands
Wait for ACK
or NACK
ACK
End of Get
NACK
Ai14631
Doc ID 17845 Rev 2
5/27
京公网安备 11010802033920号
Copyright © 2005-2026 EEWORLD.com.cn, Inc. All rights reserved
电子工程世界
