ST AN3262 Application note
Using the over-the-air bootloader with STM32W108 devices
Application (Up to 116 Kbytes)
OTA Bootloader (12 Kbytes)
Total of 128 Kbytes
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).
AN3262
Application note
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
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 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Communication protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Bootloader command set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Get command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Get Version & Read Protection Status command . . . . . . . . . . . . . . . . . . . 8
3.3 Get ID command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Read Memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 Go command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Write Memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.7 Erase Memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.8 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-topoint 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. 802.15.4 packet format for unicast packet transmission
Frame
Control
(2 bytes)
0x61 0xCC
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. 802.15.4 packet format for broadcast packet transmission
Frame
Control
(2 bytes)
0x01 0xC8
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
Ta bl e 1 lists commands supported by the OTA bootloader. A detailed command-by-
command protocol description follows.
Table 1. OTA bootloader commands
Command Command code Command description
(1)
G
ET
GET VERSION
ET ID
G
RASE 0x43 Erases memory pages of selected device.
E
W
RITE MEMORY 0x31 Writes up to 96 bytes in memory of selected device.
WRITE INCREMENTAL
MEMORY
(1)
(1)
(2)
READ MEMORY 0x11
O 0x21 Starts the code at a given location for a given device.
G
1. This command is supported by unicast and broadcast packets, while all the other are unicast only.
2. The WRITE INCREMENTAL MEMORY command is the only one not included in the original USART bootloader
command set.
0x00 Gets version number and list of commands allowed.
0x01
Gets bootloader version and Read Protection status of
the Flash memory.
0x02 Gets chip ID of device.
Writes up to 96 bytes in memory of selected device
0x36
incrementing next write address on device
automatically.
Reads up to 96 bytes of memory starting from a userspecified address.
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).
Each packet is either accepted (ACK) or discarded (NACK):
● ACK = 0x79
● NACK = 0x1F
4/27 Doc ID 17845 Rev 2
AN3262 Bootloader command set
Ai14631
Send 0x00 + 0xFF
Start Get
Wait for ACK
or NACK
Receive the number of bytes
(version+commands)
Receive the bootloader version
Receive the supported commands
Wait for ACK
or NACK
End of Get
NACK
ACK
NACK
ACK
3.1 GET command
The GET command is used to determine the version of the bootloader and the supported
commands. When the bootloader receives the G
version and the supported command codes to the host as shown in the figures below.
ET command, it transmits the bootloader
Figure 4. G
ET command (host side)
Doc ID 17845 Rev 2 5/27
Bootloader command set AN3262
Ai14632
Send ACK byte
Start Get
Received
byte = 0x00+0xFF?
Send the number of bytes
(version+commands)
Send the bootloader version
Send the supported commands
End of Get
No
Ye s
Send NACK byte
Send ACK byte
Figure 5. GET command (device side)
All information sent by the device starting from the first ACK/NACK to the last ACK/NACK is
contained inside a single 802.15.4 packet as shown in Figure 6.
The STM32 sends the following bytes:
Byte 1: ACK
Byte 2: N = 09 (the number of bytes to follow – 1)
(Does not include the current byte and ACKs.)
Byte 3: Bootloader version (0 < Version < 255)
Byte 4: 0x00 G
Byte 5: 0x01 G
Byte 6: 0x02 GET ID
Byte 7: 0x11 R
Byte 8: 0x21 G
Byte 9: 0x31 W
Byte 10: 0x43 E
Byte 11: 0x36 W
Last byte (15): ACK
ET command
ET VERSION; and
R
EAD PROTECTION STATUS
EAD MEMORY command
O command
RITE MEMORY command
RASE command
RITE MEMORY INCREMENTAL command
6/27 Doc ID 17845 Rev 2
AN3262 Bootloader command set
Figure 6. GET packet example (unicast)
Figure 7. G
ET packet example (broadcast)
Doc ID 17845 Rev 2 7/27
Bootloader command set AN3262
Ai14633
Wait for ACK
or NACK
Receive the number of times the
read protection was disabled
Receive the bootloader version
Wait for ACK
or NACK
End of GV
(1)
NACK
ACK
Send 0x01+0xFE
Start GV
(1)
Receive the number of times the
read protection was enabled
NACK
ACK
3.2 GET VERSION & READ PROTECTION STATUS command
The GET VERSION & READ PROTECTION STATUS command is used to get the bootloader
version and the read protection status. When the bootloader receives the command, it
transmits the information described below (version, read protection: number of times it was
enabled and disabled) to the host.
Figure 8. Get Version & Read Protection Status command: host side
1. GV = Get Version & Read Protection Status.
8/27 Doc ID 17845 Rev 2
AN3262 Bootloader command set
Ai14634
Send ACK byte
Start GV
(1)
Received
byte = 0x01+0xFE?
Send the bootloader version
Option byte 2
End of GV
(1)
No
Ye s
Send NACK byte
Send ACK byte
Option byte 1
Figure 9. Get Version & Read Protection Status command: device side
1. GV = Get Version & Read Protection Status.
The STM32 device sends the following bytes:
Byte 1: ACK
Byte 2: Bootloader version (0 < Version ≤ 255)
Byte 3: Option byte 1: 0x00 to keep the compatibility with generic
Byte 4: Option byte 2: 0x00 to keep the compatibility with generic
Byte 5: ACK
bootloader protocol
bootloader protocol
Doc ID 17845 Rev 2 9/27
Loading...