AN3262 Datasheet, PDF (1/27 Pages) STMicroelectronics – Using the over-the-air bootloader with STM32W108 devices

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
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