1. FOTA presentation
This application aims to demonstrate the FOTA feature over Wi-Fi.
The application starts in STA mode and connects to an AP (gateway/hotspot/etc) available in the range. The credentials (SSID & password) of the AP must be configured by the user in the file "app_config.h".
Once a device is connected, it creates and runs the FOTA task while awaiting an event trigger to start the FOTA procedure.
FOTA options can be configured in the file "app_config.h".
By default, in the FOTA application for NUCLEO-U575ZI-Q, a timer is used to trigger the FOTA event, the user button of the X-NUCLEO is also used in this example to trigger the FOTA event.
The results of the FOTA request are displayed through UART on the HyperTerminal.
There are two different types of FOTA feature:
- One is compatible with the NUCLEO-U575ZI-Q board, it allows updating the STM32 NUCLEO-U575ZI-Q and the ST67W61 targets using a FOTA header descriptor. These files can be generated by using the "fota_header_gen.py" python script.
- The other targets supported only update the ST67W61 target without using the FOTA header descriptor mechanism.
2. Requirements
2.1. Software and system requirements
The following software is required (minimum IDEs version):
- STM32CubeIDE toolchain V1.18.1 [1]
- IAR Embedded Workbench for ARM (EWARM) toolchain V9.30.1
- RealView Microcontroller Development Kit (MDK-ARM) toolchain V5.39
Programmer:
- STM32CubeProgrammer [2] : To flash the board with an already generated binary
HyperTerminal:
- Use the application through the serial link
- Open a HyperTerminal client connected to the Host ST-LINK COM port
The serial COM port must be configured as below:
| Baudrate | 921600 |
| Data | 8b |
| Stopbit | 1b |
| Parity | None |
| Flow control | None |
| Rx | LF |
| Tx | LF |
| Local Echo | Off |
For more details see HyperTerminal setup page.
An HTTP server serving the FOTA binaries:
- A Python script is provided in the "Projects/ST67W6X_Utilities/FOTA" folder to help with serving FOTA binaries over HTTP in a local area network (LAN) setup.
An FOTA header for NUCLEO-U575ZI-Q FOTA capable projects:
- A Python script is provided in the "Projects/ST67W6X_Utilities/FOTA" folder to help with generating a FOTA header in JSON format.
Both Python scripts are written with Python version 3.11 in mind.
2.2. Hardware requirements
This example runs on the NUCLEO-U575ZI-Q [3] board combined with the X-NUCLEO-67W61M1 board.
The X-NUCLEO-67W61M1 board is plugged to the NUCLEO-U575ZI-Q board through the Arduino connectors:
- The 5V, 3V3, GND through the CN6
- The SPI (CLK, MOSI, MISO), SPI_CS and USER_BUTTON signals through the CN5
- The BOOT, CHIP_EN, SPI_RDY and UART TX/RX signals through the CN9
The USER_BUTTON refers to the button mounted on the X-NUCLEO-67W61M1. Indeed, the user button on the STM32 Nucleo board is not used as external interrupt mode due to conflict with other EXTI pin requirement. The button must be defined with the user label USER_BUTTON and EXTI falling mode.
3. ST67W6X_FOTA application description
3.1. Project directory
The "ST67W6X_FOTA" application is available by downloading the X-CUBE-ST67W61 Package.
Refer to Project directory wiki page for project directory information.
3.2. Project description
3.2.1. Topology structure
The device (NUCLEO-U575ZI-Q + X-NUCLEO-67W61M1) is in STA mode, and it connects to a Wi-Fi local access point (hotspot/gateway/etc) which needs a connection to the internet (unless the server hosting the binary file for the FOTA operation is available on the LAN).
3.2.2. Project initialization
The different steps of the application initialization are described below:
In light blue are listed the common initialization steps between all the applications. The other steps are specific to the FOTA application.
3.3. Build and install
Refer to build and install chapter for details on how to build and download on the device.
3.4. User setup
The Python server script "HTTP_server.py" provided is given for practical reasons in order to test the FOTA feature on a local setup. A different HTTP server can be used to host the FOTA binaries. A HTTP server is required in order to serve the FOTA binaries to the FOTA application.
The Python header generation script "fota_header_gen.py" is used for NUCLEO-U575ZI-Q FOTA cable projects only, it allows generating the FOTA header in JSON format used by the FOTA application to retrieve crucial information on the served FOTA binaries. It also generates a header .h C file to be used in projects that parse the FOTA header.
3.4.1. ST67W6X default configuration
The default System configuration can be modified in "ST67W6X/Target/w6x_config.h":
/** NCP will go by default in low power mode when NCP is in idle mode */ #define W6X_POWER_SAVE_AUTO 1 /** NCP clock mode : 1: Internal RC oscillator, 2: External passive crystal, 3: External active crystal */ #define W6X_CLOCK_MODE 1
The default Wi-Fi configuration can be modified in the "ST67W6X/Target/w6x_config.h" file:
/** Define the DHCP configuration : 0: NO DHCP, 1: DHCP CLIENT STA, 2:DHCP SERVER AP, 3: DHCP STA+AP */
#define W6X_WIFI_DHCP 1
/** Define if the DNS addresses are set manually or automatically */
#define W6X_WIFI_DNS_MANUAL 0
/** String defining DNS IP 1 address to use
* @note: This address will be used only if W6X_WIFI_DNS_MANUAL equals 1 */
#define W6X_WIFI_DNS_IP_1 {208, 67, 222, 222}
/** String defining DNS IP 2 address to use
* @note: This address will be used only if W6X_WIFI_DNS_MANUAL equals 1 */
#define W6X_WIFI_DNS_IP_2 {8, 8, 8, 8}
/** String defining DNS IP 3 address to use
* @note: This address will be used only if W6X_WIFI_DNS_MANUAL equals 1 */
#define W6X_WIFI_DNS_IP_3 {0, 0, 0, 0}
/** Define the region code, supported values : [CN, JP, US, EU, 00] */
#define W6X_WIFI_COUNTRY_CODE "00"
/** Define if the country code will match AP's one.
* 0: match AP's country code,
* 1: static country code */
#define W6X_WIFI_ADAPTIVE_COUNTRY_CODE 0
/** String defining Wi-Fi hostname */
#define W6X_WIFI_HOSTNAME "ST67W61_WiFi"
The default Net configuration can be modified in the "ST67W6X/Target/w6x_config.h" file:
/** Timeout in ticks when calling W6X_Net_Recv() */ #define W6X_NET_RECV_TIMEOUT 10000 /** Timeout in ticks when calling W6X_Net_Send() */ #define W6X_NET_SEND_TIMEOUT 10000
The AT driver can be configured in "ST67W6X\Target\w61_driver_config.h":
/** Maximum number of detected AP during the scan. Cannot be greater than 50 */ #define W61_WIFI_MAX_DETECTED_AP 50 /** Debugging only: Enable AT log, i.e. logs the AT commands incoming/outcoming from/to the NCP */ #define W61_AT_LOG_ENABLE 0
Additionally, some other options can be modified in the "ST67W6X/Target" directory with different configuration files as below:
- logging_config.h: This file provides configuration for the logging component to set the log level.
- shell_config.h: This file provides configuration for shell component.
- w6x_config.h: This file provides configuration for the W6X APIs (used during initialization).
- w61_driver_config.h: This file provides configuration for the W61 configuration module.
All available defines are available in template directory "Middlewares/ST/ST67W6X_Network_Driver/Conf".
3.4.2. Application configuration
The Wi-Fi configuration used in this application is defined in "App_FOTA/App/app_config.h":
#define WIFI_SSID "YOUR_SSID" #define WIFI_PASSWORD "YOUR_PASSWORD"
The logging output mode can be modified in "App_FOTA/App/app_config.h":
/** Select output log mode [0: printf / 1: UART / 2: ITM] */ #define LOG_OUTPUT_MODE 1
The host low power mode can be modified in "App_FOTA/App/app_config.h":
/** Low power configuration [0: disable / 1: sleep / 2: stop / 3: standby] */ #define LOW_POWER_MODE 1
The host debugger pins can be modified in "App_FOTA/App/app_config.h":
/** * Enable/Disable MCU Debugger pins (dbg serial wires) * @note by HW serial wires are ON by default, need to put them OFF to save power */ #define DEBUGGER_ENABLED 1
The FOTA client configuration can be modified in "App_FOTA/App/app_config.h":
/** Timeout value to set the FOTA timer to when the FOTA application encountered an error for the first time. * This allows to tune the timeout value before doing a retry attempt. (not applicable if FOTA timer is not used)*/ #define FOTA_TIMEOUT 20000 /** Value in milliseconds of the timer configured in the echo FOTA application, * it will trigger the FOTA update event after the amount of time specified once configured. */ #define FOTA_TRIGGER_TIMER 10000 /** Delay to wait before rebooting the host device, waiting for NCP device to finish update */ #define FOTA_DELAY_BEFORE_REBOOT 16000 /** Stack size of the FOTA application, this value needs to take into account the HTTP client * and NCP OTA static data allocation */ #define FOTA_TASK_STACK_SIZE 2048 /** The max size of the URI supported, this because the buffer * that will receive this info is allocated at compile time (static) */ #define FOTA_URI_MAX_SIZE 128 /** Default HTTP server address */ #define FOTA_HTTP_SERVER_ADDR "192.168.8.105" /** Default HTTP port */ #define FOTA_HTTP_SERVER_PORT 8000 /** As specified in RFC 1035 Domain Implementation and Specification * from November 1987, domain names are 255 octets or less */ #define FOTA_MAX_DOMAIN_NAME_SIZE 255U /** The folder containing the FOTA header, ST67 binary and the STM32 binary */ #define FOTA_HTTP_URI_TARGET "/STM32U575ZI_NUCLEO" /** Root folder of interest on the HTTP server */ #define FOTA_HTTP_COMMON_URI "/download" FOTA_HTTP_URI_TARGET /** Default URI for the ST67 binary, should be smaller in bytes size than the value defined by FOTA_URI_MAX_SIZE */ #define FOTA_HTTP_URI FOTA_HTTP_COMMON_URI "/st67w611m_mission_t01_v2.0.75.bin.ota" /** Default URI for the STM32 binary, should be smaller in bytes size than the value defined by FOTA_URI_MAX_SIZE */ #define FOTA_HTTP_URI_STM32 FOTA_HTTP_COMMON_URI "/fota_ST67W6X_FOTA.bin" /** Default URI for the FOTA header */ #define FOTA_HTTP_URI_HEADER FOTA_HTTP_COMMON_URI "/ST67W611_STM32U575ZI_NUCLEO.json"
3.4.3. Python header generation configuration
The Python script for the header generation can be configured by passing parameters.
There is two set of configuration for executing the script :
- It is either possible to generate a header description file in .h format using "gen_header"
- Or it is possible to generate the header content values using "install_header", outputting a JSON formatted file containing all the information necessary for FOTA.
usage: fota_header_gen.py [-h] {install_header,gen_header} ...
A simple argument parser example.
positional arguments:
{install_header,gen_header}
subcommand help
install_header Install header to an existing binary
gen_header Generate header c file for the FOTA header structure
options:
-h, --help show this help message and exit
- Install_header option
When using "install_header" option, the following options can be set:
Starting the script...
usage: fota_header_gen.py install_header [-h] -i INPUT -n ST67 -t TARGET -r BOARD_REVISION -b PREFIX_BOARD -w FIRMWARE_TYPE [-o OUTPUT_DIR] [-f FORMAT] -v VERSION -c ST67_VERSION [-l]
options:
-h, --help show this help message and exit
-i INPUT, --input INPUT
Input file path to the STM32 binary
-n ST67, --st67 ST67 Network co-processor binary file path that matches with given input file
-t TARGET, --target TARGET
Target name of the STM32
-r BOARD_REVISION, --board_revision BOARD_REVISION
Board revision of the STM32
-b PREFIX_BOARD, --prefix_board PREFIX_BOARD
Target board name of the STM32
-w FIRMWARE_TYPE, --firmware_type FIRMWARE_TYPE
ST67 firmware type
-o OUTPUT_DIR, --output_dir OUTPUT_DIR
Output directory path
-f FORMAT, --format FORMAT
Choose format of version either json, c or type "both" to add both the binary
-v VERSION, --version VERSION
Version of the STM32 binary (in x.y.z format)
-c ST67_VERSION, --st67_version ST67_VERSION
Version of the ST67 binary (in x.y.z format)
-l, --verbose Enable verbose mode
An example of usage with required parameters is shown below:
python fota_header_gen.py install_header -v 1.0.0 -c 2.0.75 -t STM32U575ZI -b NUCLEO -r A -w NCP1 -n ../Binaries/NCP_Binaries/st67w611m_mission_t01_v2.0.75.bin.ota -i ../../NUCLEO-U575ZI-Q/Applications/ST67W6X/ST67W6X_FOTA/STM32CubeIDE/Debug/ST67W6X_FOTA.bin
| Parameter | Description | Example |
|---|---|---|
| -v <STM32 version> | Specify the version of the STM32 binary used for FOTA, needs to be in a x.y.z format | -v 1.0.0 |
| -c <ST67W611M1 version> | Specify the version of the ST67W611M1 binary used for FOTA, needs to be in a x.y.z format | -c 2.0.75 |
| -t <STM32 board name> | Specify the board name of the STM32 binary used for FOTA | -t STM32U575ZI |
| -b <STM32 board prefix> | Specify the prefix of the STM32 board used for FOTA, it allows to specify what type of board is used | -b NUCLEO |
| -r <STM32 Board revision> | Specify the revision of the STM32 board | -r A |
| -w <ST67W611M1 binary type> | Specify the type of firmware of the ST67W611M1 binary used for FOTA | -w NCP1 |
| -r <STM32 Board revision> | Specify the revision of the STM32 board | -r A |
| -n <ST67W611M1 binary path> | Path to the ST67W611M1 binary used for FOTA | -n ../Binaries/NCP_Binaries/st67w611m_mission_t01_v2.0.75.bin.ota |
| -i <STM32 Board path> | Path to the STM32 binary used for FOTA | -i ../../NUCLEO-U575ZI-Q/Applications/ST67W6X/ST67W6X_FOTA/STM32CubeIDE/Debug/ST67W6X_FOTA.bin |
| -o <output path> | Is an optional parameter used to set the location of the generated files, by default it points to the current working directory | -o ../Binaries/NCP_Binaries/ |
- gen_header option
When using "gen_header" option, the output_dir arguments allows choosing were to create and generate the header description in C format. This option is typically used at compilation time when the codes need the header structure definition to successfully compile.
This configuration is done at build time for any NUCLEO-U575ZI-Q application supporting the FOTA feature.
Starting the script...
usage: fota_header_gen.py gen_header [-h] [-o OUTPUT_DIR] [-l]
options:
-h, --help show this help message and exit
-o OUTPUT_DIR, --output_dir OUTPUT_DIR
Output directory path
-l, --verbose Enable verbose mode
3.4.4. HTTP server python configuration
The Python script for the HTTP server exposing the ST67W611M1 binaries can be configured in the Python "HTTP_server.py" file itself:
# IP to use for the server
# if empty it bind itself to all interfaces available else it will bind to the IP specified
IP = ''
# Port to use for the server
PORT = 8000
HTTPS_PORT = 8443
# Directory where the firmware files are stored, those will be exposed by the server
FIRMWARE_DIR = "../Binaries/NCP_Binaries"
# Name of the file containing the firmware version information, it will be exposed by the server
FIRMWARE_VERSION_FILE = "NCP.json"
# Paths exposed by the server for the firmware version file (ex doing GET /check_update will return the file located at FIRMWARE_VERSION_FILE)
HTTP_FIRMWARE_VERSION_FILE_PATH = "/check_update"
# Paths exposed by the server for the firmware files (ex doing GET /download/firmware.bin will return the file located at FIRMWARE_DIR/firmware.bin)
HTTP_FIRMWARE_DIR_PATH = "/download/"
# Main html page of the server
INDEX_PAGE = "/"
# Path exposed by the server to list all the firmware files available
BINARIES = "/binaries"
HTTP_DEFAULT_VERSION = "HTTP/1.1"
# Extension of the files to expose by the server
FILE_EXTENSIONS_TO_SHOW = [".bin", ".ota", ".xz", ".json"]
# logging level
DEFAULT_LOGGING_LEVEL = "DEBUG"
# Multi-threading option for the server itself to handle multiple HTTP(s) request
DEFAULT_THREADING_OPTION = True
# Default SSL certificate file
DEFAULT_SSL_CERTFILE = "cert.pem"
# Default SSL key file
DEFAULT_SSL_KEYFILE = "key.pem"
The Python script can also be configured at runtime:
python HTTP_server.py --port 8080 --ip 127.0.0.1 --firmware-dir /path/to/firmware_dir
The help description of the script can be obtained using the following parameter:
python HTTP_server.py --help
This results in the following output:
usage: HTTP_server.py [-h] [-p PORT] [-ps HTTPS_PORT] [-i IP] [-hv HTTP_VERSION] [-l LOG_LEVEL] [-t] [-f FIRMWARE_DIR] [-c CERTFILE] [-k KEYFILE] [-s]
Start the FOTA HTTP server.
options:
-h, --help show this help message and exit
-p PORT, --port PORT Port to run the server on
-ps HTTPS_PORT, --https-port HTTPS_PORT
Port to run the HTTPS server on
-i IP, --ip IP IP address to run the server on
-hv HTTP_VERSION, --http-version HTTP_VERSION
HTTP version to use (e.g., HTTP/1.1, HTTP/2)
-l LOG_LEVEL, --log-level LOG_LEVEL
Logging level (e.g., DEBUG, INFO, WARNING, ERROR, CRITICAL)
-t, --threaded Run the server in threaded mode
-f FIRMWARE_DIR, --firmware-dir FIRMWARE_DIR
Directory where the firmware files are stored
-c CERTFILE, --certfile CERTFILE
Path to the SSL certificate file
-k KEYFILE, --keyfile KEYFILE
Path to the SSL key file
-s, --enable_https Enable or disable HTTPS server
Default parameters are configured for a simple HTTP server to run. A important option to consider changing is the firmware directory configuration that set the directory where the firmware files are stored.
Following parameters can be set but not limited to: Get the list of existing parameters argument that are settable.
-h or --help
Set the port of the HTTP server:
-p <numeric value> or --port <numeric value>
Set the port of the HTTPS server:
-ps <numeric value> or --https-port <numeric value>
Set IP address of the server:
-i <ip format x.x.x.x> or --ip <ip format x.x.x.x>
Logging level regarding errors, tracebacks, debugging information:
-l <DEBUG, INFO, WARNING, ERROR, CRITICAL> or --log-level <DEBUG, INFO, WARNING, ERROR, CRITICAL>
The directory containing the FOTA binary to be exposed by the HTTP server:
-f <binary/folder/> or --firmware-dir <my/binary/folder/>
Enable the HTTPS along side the HTTP server:
-s or --enable-https
Location of the certificate file for HTTPS, required for HTTPS:
-c <certificate/file.pem> or --certfile <certificate/file.pem>
Location of the keyfile for HTTPS, required for HTTPS:
-k <key/file.pem> or --keyfile <key/file.pem>
3.5. How it works
3.5.1. Python FOTA header generation script (NUCLEO-U575ZI-Q)
The Python script generates a FOTA header depending on the arguments provided, all generated files are located in a folder.
The folder is named according to the argument -b (board name) and -t (board prefix) specified.
The result folder is named <board_prefix>_<board_name> and its location on the system can be defined by the -o argument.
Consider the following example,
python fota_header_gen.py install_header -v 2.0.0 -c 2.0.75 -t STM32U575ZI -b NUCLEO -r A -w NCP1 -n ../Binaries/NCP_Binaries/st67w611m_mission_t01_v2.0.75.bin.ota -i ../../NUCLEO-U575ZI-Q/Applications/ST67W6X/ST67W6X_FOTA/STM32CubeIDE/Debug/ST67W6X_FOTA.bin
The folder generated is the following:
The containing the files shown below:
And the FOTA header in JSON format has the values shown below:
These files should be exposed by an HTTP server.
3.5.2. Python HTTP server script (all targets supporting FOTA)
The Python script exposes a given directory defined by FIRMWARE_DIR and only exposes files with extension defined by FILE_EXTENSIONS_TO_SHOW.
By default, the script serves the files using the /download/ URI prefix followed by the requested file.
The /download/ URI prefix can be overridden by changing HTTP_FIRMWARE_DIR_PATH value.
To use the Python HTTP server, the script needs to be run before starting the FOTA application.
python HTTP_server.py
Output should be similar to the following :
2025-02-12 14:45:40,292 - DEBUG - FOTA updates directory exposed: ../../ST67_Tools/ST67_Binaries
2025-02-12 14:45:40,293 - DEBUG - HTTP version: HTTP/1.1
2025-02-12 14:45:40,293 - DEBUG - Server version: BaseHTTP/0.6
2025-02-12 14:45:40,293 - DEBUG - System version: 3.11.9 (tags/v3.11.9:de54cf5, Apr 2 2024, 10:12:12) [MSC v.1938 64 bit (AMD64)]
2025-02-12 14:45:40,293 - DEBUG - Server address: ('0.0.0.0', 8000)
2025-02-12 14:45:40,293 - DEBUG - Server port: 8000
2025-02-12 14:45:40,293 - DEBUG - Server socket: <socket.socket fd=516, family=2, type=1, proto=0, laddr=('0.0.0.0', 8000)>
2025-02-12 14:45:40,294 - DEBUG - Server threading: False
2025-02-12 14:45:40,294 - DEBUG - Server timeout: None
2025-02-12 14:45:40,294 - DEBUG - Server request handler: <class '__main__.FOTARequestHandler'>
2025-02-12 14:45:40,294 - DEBUG - Server request handler firmware version file: ST67.json
2025-02-12 14:45:40,294 - DEBUG - Server request handler firmware version file path: /check_update
2025-02-12 14:45:40,294 - DEBUG - Server request handler firmware directory path: /download/
2025-02-12 14:45:40,294 - DEBUG - Server request handler file extensions to show: ['.bin', '.ota', '.xz', '.json']
2025-02-12 14:45:40,294 - INFO - Starting server on 0.0.0.0:8000
When a resource is downloaded/requested from the server a log should appear, similar to the following :
127.0.0.1 - - [12/Feb/2025 14:48:49] "GET / HTTP/1.1" 200 - 127.0.0.1 - - [12/Feb/2025 14:48:49] "GET /favicon.ico HTTP/1.1" 200 - 127.0.0.1 - - [12/Feb/2025 14:49:20] "GET /download/ST67W611M1.bin.ota HTTP/1.1" 200 -
3.5.3. STM32 FOTA application STM32 and ST67W611M1 (NUCLEO-U575ZI-Q).
Note : After executing this example, the SWAP_BANK option byte is set. Use STM32CubeProgrammer to change this option byte back to "Not swapped" to be able to load a binary or debug through any IDE.
Note : The toolchains supported have additional configurations in order to ensure that the NUCLEO-U575ZI-Q binary generated has a size aligned on 16 bytes. This is required for the FOTA feature in order to write in the NUCLEO-U575ZI-Q flash bank without error.
The connection of the STA is done after a scan to the local AP, and the device receives an IP address from the DHCP server of the selected local AP.
The FOTA task is created and launched, awaiting a specific event before launching the FOTA process
A timer is used to trigger the FOTA event after a set amount of time.
SetFOTATimer(FOTA_TIMER_VALUE_IN_MS); StartFOTATimer();
It performs a callback after the timer that sets the FOTA event expires.
void vFOTATimerCallback(TimerHandle_t xTimer)
{
(void)TriggerFOTAUpdate();
}
Another option is to use the user button to trigger the FOTA event.
void HAL_GPIO_EXTI_Falling_Callback(uint16_t pin)
{
...
/* Callback when user button is pressed */
if (pin == USER_BUTTON_Pin)
{
TriggerFOTAUpdate();
Button_Falling_Callback();
}
}
Once triggered, the FOTA starts using the parameters specified in the configuration file "App_FOTA\App\app_config.h" in order to establish a connection and retrieve data from the HTTP server.
It starts by fetching the FOTA header to retrieve information regarding the binaries to be downloaded.
After fetching the JSON header file successfully, it attempts to read it and use the information to determine if the update process should go forward.
Information is stored for later use regarding the integrity check of the STM32 binary downloaded for example.
Once the verification steps have passed, the update of the ST67W611M1 is done while retrieving data from the HTTP communication.
Once all data is received from the HTTP server, it means that all have been transferred on the ST67W611M1 device.
After this step is completed, the STM32 binary is downloaded and stored in the NUCLEO-U575ZI-Q flash memory.
When this step is done, an integrity check is launched to ensure all operations were successful, using SHA256 computation to compare with the value present in the FOTA header retrieved previously.
To apply the update, a verification on ST67W611M1 side occurs and validates that the ST67W611M1 update received is valid and can be used.
The ST67W611M1 immediately proceeds to reboot on the new firmware and the FOTA application awaits a given amount of time before rebooting the NUCLEO-U575ZI-Q device.
The NUCLEO-U575ZI-Q is configured to boot on the flash bank where the new downloaded binary is located.
This means ST67W611M1 reboots two times and the host device one time only. After the reboots, a new communication is established with the updated ST67W611M1.
Before the reboot sequence happens, a completion callback is executed by the FOTA task. This callback function can be set using dedicated setter API :
/* Register the callback to be called when the FOTA process is completed */
Fota_RegisterCallbacks(Fota_CompletionCb, NULL);
Results should be similar to the one shown below:
# build: 10:06:12 May 12 2025
--------------- Host info ---------------
Host FW Version: 1.0.0
--------------- ST67W6X info ------------
ST67W6X MW Version: 1.0.0
AT Version: 1.0.0.1
SDK Version: 2.0.70
MAC Version: 1.6.38
Build Date: May 6 2025 12:39:15
Module ID:
BOM ID: 0
Manufacturing Year: 2000
Manufacturing Week: 00
Battery Voltage: 3.308 V
Trim Wi-Fi hp: 4,4,4,4,4,4,3,3,3,3,3,3,2,3
Trim Wi-Fi lp: 3,4,4,5,5,6,6,6,6,6,6,6,6,6
Trim BLE: 2,2,2,1,2
Trim XTAL: 38
MAC Address: 40:82:7b:00:0e:6a
Anti-rollback Bootloader: 0
Anti-rollback App: 0
-----------------------------------------
mount success
Wi-Fi init is done
Net init is done
MQTT init is done
Starting FOTA task
ready
Application started from bank 1
SCAN DONE
Cb informed APP that WIFI SCAN DONE.
MAC : [c8:7f:54:af:85:10] | Channel: 6 | OPEN | RSSI: -44 | SSID: ASUS_10_2G
Connecting to Local Access Point
MAC : [50:91:e3:73:bc:03] | Channel: 1 | WPA2 | RSSI: -45 | SSID: TP-Link_BC03
MAC : [42:82:7b:00:0e:af] | Channel: 1 | WPA2 | RSSI: -48 | SSID: ST67W6X_AP
MAC : [94:83:c4:46:c0:b3] | Channel: 8 | WPA2 | RSSI: -48 | SSID: GL-A1300-0b1
MAC : [78:0c:f0:6c:b4:a0] | Channel: 6 | WPA-EAP | RSSI: -51 | SSID: STWLAN2
MAC : [78:0c:f0:6c:b4:a1] | Channel: 6 | WPA-EAP | RSSI: -51 | SSID: STSMARTMOBILE
MAC : [78:0c:f0:6c:b4:a2] | Channel: 6 | OPEN | RSSI: -51 | SSID: STGUEST
MAC : [30:de:4b:d3:b9:4d] | Channel: 1 | WPA2 | RSSI: -70 | SSID: TP-Link_B94D
MAC : [78:0c:f0:74:45:80] | Channel: 1 | WPA-EAP | RSSI: -73 | SSID: STWLAN2
MAC : [78:0c:f0:74:45:81] | Channel: 1 | WPA-EAP | RSSI: -73 | SSID: STSMARTMOBILE
MAC : [78:0c:f0:74:45:82] | Channel: 1 | OPEN | RSSI: -73 | SSID: STGUEST
MAC : [78:0c:f0:79:02:22] | Channel: 11 | OPEN | RSSI: -74 | SSID: STGUEST
MAC : [78:0c:f0:79:02:20] | Channel: 11 | WPA-EAP | RSSI: -75 | SSID: STWLAN2
MAC : [78:0c:f0:79:02:21] | Channel: 11 | WPA-EAP | RSSI: -75 | SSID: STSMARTMOBILE
MAC : [78:0c:f0:78:64:c0] | Channel: 11 | WPA-EAP | RSSI: -87 | SSID: STWLAN2
MAC : [78:0c:f0:78:64:c2] | Channel: 11 | OPEN | RSSI: -88 | SSID: STGUEST
MAC : [78:0c:f0:78:64:c1] | Channel: 11 | WPA-EAP | RSSI: -88 | SSID: STSMARTMOBILE
NCP is treating the connection request
DHCP client start, this may take few seconds
Connected to following Access Point :
[c8:7f:54:af:85:10] Channel: 6 | RSSI: 0 | SSID: ASUS_10_2G
Station got an IP from Access Point : 192.168.179.171
Connection success
***************FOTA TEST ***************
Init FOTA callbacks for SHELL usage
IP Address from Hostname [192.168.179.104]: 192.168.179.104
FOTA update started: server=192.168.179.104, port=8000, uri=/download/STM32U575ZI_NUCLEO/ST67W611_STM32U575ZI_NUCLEO.json
Socket creation done
Socket 0 connected
Socket 0 connected
HTTP request send data success (153)
Socket 0 disconnected
total len 347
Received 347 bytes of header data, total accumulated: 0 bytes
FOTA header fully received
FOTA header:
Magic number: ST67W611
Header protocol version: 1.0.0
Data type: STM32U575ZI
Firmware type: NCP1
stm32_app_ver version: 2.0.0
st67_ver version: 2.1.75
File hash:
3B0541D6D6A82930E5050BFC74DC333B4DE4382D38727F801A365E4A240D9D15
IP Address from Hostname [192.168.179.104]: 192.168.179.104
FOTA update started: server=192.168.179.104, port=8000, uri=/download/STM32U575ZI_NUCLEO/st67w611m_mission_t01_v2.0.75.bin.ota
Socket creation done
Socket 0 connected
Socket 1 connected
HTTP request send data success (144)
total len 1399904
ST67 OTA header successfully transferred
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
...
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
Socket 0 disconnected
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 1299 xfer to ST67
FOTA data transfer to ST67 finished
IP Address from Hostname [192.168.179.104]: 192.168.179.104
Mass erase done
FOTA update started: server=192.168.179.104, port=8000, uri=/download/STM32U575ZI_NUCLEO/fota_ST67W6X_FOTA.bin
Socket creation done
Socket 0 connected
Socket 2 connected
HTTP request send data success (141)
total len 233136
Wrote 1856 bytes to flash at address 8100000
Wrote 2048 bytes to flash at address 8100740
Wrote 2048 bytes to flash at address 8100f40
...
Wrote 2048 bytes to flash at address 8132f40
Wrote 2048 bytes to flash at address 8133740
Wrote 2048 bytes to flash at address 8133f40
Wrote 2048 bytes to flash at address 8134740
Wrote 2048 bytes to flash at address 8134f40
Socket 0 disconnected
Wrote 2048 bytes to flash at address 8135740
Wrote 2048 bytes to flash at address 8135f40
Wrote 2048 bytes to flash at address 8136740
Wrote 2048 bytes to flash at address 8136f40
Wrote 2048 bytes to flash at address 8137740
Wrote 2048 bytes to flash at address 8137f40
Wrote 1904 bytes to flash at address 8138740
FOTA data transfer to ST67 finished
STM32 integrity check passes
FOTA transfer done
FOTA task waiting for application acknowledgment
Station disconnected from Access Point
Reason: WLAN_FW_DISCONNECT_BY_USER_WITH_DEAUTH
Wi-Fi Disconnect success
FOTA task done
<ESC>[33m***************FOTA SHELL SUCCESS *******
<ESC>[0m<ESC>[36mw61/><ESC>[0mFOTA task waiting 16000 ms before rebooting
w61/>#### Welcome to ST67W6X FOTA Application #####
# build: 10:53:57 May 9 2025
--------------- Host info ---------------
Host FW Version: 2.0.0
--------------- ST67W6X info ------------
ST67W6X MW Version: 1.0.0
AT Version: 1.0.0.1
SDK Version: 2.1.75
MAC Version: 1.6.38
Build Date: May 6 2025 12:39:15
Module ID:
BOM ID: 0
Manufacturing Year: 2000
Manufacturing Week: 00
Battery Voltage: 3.306 V
Trim Wi-Fi hp: 4,4,4,4,4,4,3,3,3,3,3,3,2,3
Trim Wi-Fi lp: 3,4,4,5,5,6,6,6,6,6,6,6,6,6
Trim BLE: 2,2,2,1,2
Trim XTAL: 38
MAC Address: 40:82:7b:00:0e:6a
Anti-rollback Bootloader: 0
Anti-rollback App: 0
-----------------------------------------
mount success
Wi-Fi init is done
Net init is done
MQTT init is done
Starting FOTA task
ready
Application started from bank 2
The following diagram summarizes the different steps performed when FOTA operation is triggered:
3.5.4. STM32 FOTA application ST67W611M1 only (other FOTA supported targets)
The connection of the STA is done after a scan to the local AP, and the device receive an IP address from the DHCP server of the selected local AP. The FOTA task will be created and launched, awaiting a specific event before launching the FOTA process
A timer is used to trigger the FOTA event after a set amount of time.
SetFOTATimer(FOTA_TIMER_VALUE_IN_MS); StartFOTATimer();
It makes a callback after the timer that sets the FOTA event expires.
void vFOTATimerCallback(TimerHandle_t xTimer)
{
(void)TriggerFOTAUpdate();
}
Another option is to use the user button that to rigger the FOTA event.
void HAL_GPIO_EXTI_Falling_Callback(uint16_t pin)
{
...
/* Callback when user button is pressed */
if (pin == USER_BUTTON_Pin)
{
TriggerFOTAUpdate();
Button_Falling_Callback();
}
}
Once triggered, the FOTA starts using the parameters specified in the configuration file "App_FOTA\App\app_config.h" in order to establish a connection and retrieve data from the HTTP server.
The update of the ST67W611M1 is done while retrieving data from the HTTP communication.
Once all data is received from the HTTP server, it should be transferred by the host on the ST67W611M1 device.
A verification on ST67W611M1 side occurs and validates that the update received is valid and can be used.
The ST67W611M1 immediately proceeds to reboot on the new firmware and the FOTA application awaits a given amount of time before rebooting the host device. This means ST67W611M1 reboots two times and the host device one time only. After the reboots, a new communication is established with the updated ST67W611M1.
Before the reboot sequence happens, a completion callback is executed by the FOTA task. This callback can be set using dedicated setter API :
/* Register the callback to be called when the FOTA process is completed */
Fota_RegisterCallbacks(Fota_CompletionCb, NULL);
Results should be similar to the one shown below:
# build: 10:06:12 May 12 2025
--------------- Host info ---------------
Host FW Version: 1.0.0
--------------- ST67W6X info ------------
ST67W6X MW Version: 1.0.0
AT Version: 1.0.0.1
SDK Version: 2.0.70
MAC Version: 1.6.38
Build Date: May 6 2025 12:39:15
Module ID:
BOM ID: 0
Manufacturing Year: 2000
Manufacturing Week: 00
Battery Voltage: 3.308 V
Trim Wi-Fi hp: 4,4,4,4,4,4,3,3,3,3,3,3,2,3
Trim Wi-Fi lp: 3,4,4,5,5,6,6,6,6,6,6,6,6,6
Trim BLE: 2,2,2,1,2
Trim XTAL: 38
MAC Address: 40:82:7b:00:0e:6a
Anti-rollback Bootloader: 0
Anti-rollback App: 0
-----------------------------------------
mount success
Wi-Fi init is done
Net init is done
MQTT init is done
Starting FOTA task
ready
STM32 Flash bank is not swapped, STM32 currently executing code in primary bank
SCAN DONE
Cb informed APP that WIFI SCAN DONE.
MAC : [c8:7f:54:af:85:10] | Channel: 6 | OPEN | RSSI: -44 | SSID: ASUS_10_2G
Connecting to Local Access Point
MAC : [50:91:e3:73:bc:03] | Channel: 1 | WPA2 | RSSI: -45 | SSID: TP-Link_BC03
MAC : [42:82:7b:00:0e:af] | Channel: 1 | WPA2 | RSSI: -48 | SSID: ST67W6X_AP
MAC : [94:83:c4:46:c0:b3] | Channel: 8 | WPA2 | RSSI: -48 | SSID: GL-A1300-0b1
MAC : [78:0c:f0:6c:b4:a0] | Channel: 6 | WPA-EAP | RSSI: -51 | SSID: STWLAN2
MAC : [78:0c:f0:6c:b4:a1] | Channel: 6 | WPA-EAP | RSSI: -51 | SSID: STSMARTMOBILE
MAC : [78:0c:f0:6c:b4:a2] | Channel: 6 | OPEN | RSSI: -51 | SSID: STGUEST
MAC : [30:de:4b:d3:b9:4d] | Channel: 1 | WPA2 | RSSI: -70 | SSID: TP-Link_B94D
MAC : [78:0c:f0:74:45:80] | Channel: 1 | WPA-EAP | RSSI: -73 | SSID: STWLAN2
MAC : [78:0c:f0:74:45:81] | Channel: 1 | WPA-EAP | RSSI: -73 | SSID: STSMARTMOBILE
MAC : [78:0c:f0:74:45:82] | Channel: 1 | OPEN | RSSI: -73 | SSID: STGUEST
MAC : [78:0c:f0:79:02:22] | Channel: 11 | OPEN | RSSI: -74 | SSID: STGUEST
MAC : [78:0c:f0:79:02:20] | Channel: 11 | WPA-EAP | RSSI: -75 | SSID: STWLAN2
MAC : [78:0c:f0:79:02:21] | Channel: 11 | WPA-EAP | RSSI: -75 | SSID: STSMARTMOBILE
MAC : [78:0c:f0:78:64:c0] | Channel: 11 | WPA-EAP | RSSI: -87 | SSID: STWLAN2
MAC : [78:0c:f0:78:64:c2] | Channel: 11 | OPEN | RSSI: -88 | SSID: STGUEST
MAC : [78:0c:f0:78:64:c1] | Channel: 11 | WPA-EAP | RSSI: -88 | SSID: STSMARTMOBILE
NCP is treating the connection request
DHCP client start, this may take few seconds
Connected to following Access Point :
[c8:7f:54:af:85:10] Channel: 6 | RSSI: 0 | SSID: ASUS_10_2G
Station got an IP from Access Point : 192.168.179.171
Connection success
***************FOTA TEST ***************
Init FOTA callbacks for SHELL usage
IP Address from Hostname [192.168.179.104]: 192.168.179.104
FOTA update started: server=192.168.179.104, port=8000, uri=/download/STM32U575ZI_NUCLEO/st67w611m_mission_t01_v2.0.75.bin.ota
Socket creation done
Socket 0 connected
Socket 1 connected
HTTP request send data success (144)
total len 1399904
ST67 OTA header successfully transferred
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
...
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
Socket 0 disconnected
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 2048 xfer to ST67
FOTA data length 1299 xfer to ST67
FOTA data transfer to ST67 finished
FOTA data transfer to ST67 finished
FOTA transfer done
FOTA task waiting for application acknowledgment
Station disconnected from Access Point
Reason: WLAN_FW_DISCONNECT_BY_USER_WITH_DEAUTH
Wi-Fi Disconnect success
FOTA task done
<ESC>[33m***************FOTA SHELL SUCCESS *******
<ESC>[0m<ESC>[36mw61/><ESC>[0mFOTA task waiting 16000 ms before rebooting
w61/>#### Welcome to ST67W6X FOTA Application #####
# build: 10:53:57 May 9 2025
--------------- Host info ---------------
Host FW Version: 1.0.0
--------------- ST67W6X info ------------
ST67W6X MW Version: 1.0.0
AT Version: 1.0.0.1
SDK Version: 2.1.75
MAC Version: 1.6.38
Build Date: May 6 2025 12:39:15
Module ID:
BOM ID: 0
Manufacturing Year: 2000
Manufacturing Week: 00
Battery Voltage: 3.306 V
Trim Wi-Fi hp: 4,4,4,4,4,4,3,3,3,3,3,3,2,3
Trim Wi-Fi lp: 3,4,4,5,5,6,6,6,6,6,6,6,6,6
Trim BLE: 2,2,2,1,2
Trim XTAL: 38
MAC Address: 40:82:7b:00:0e:6a
Anti-rollback Bootloader: 0
Anti-rollback App: 0
-----------------------------------------
mount success
Wi-Fi init is done
Net init is done
MQTT init is done
Starting FOTA task
ready
The following diagram summarizes the different steps performed when FOTA operation is triggered.
3.6. Memory footprint
| Module | Description |
|---|---|
| [Driver] HAL/CMSIS/BSP | STM32 CMSIS Cortex, HAL and LL, Board Specific Package drivers |
| [Project] Core | Native STM32 core components |
| [Project] App | Main part of the application |
| [Project] Target | Configuration files for ST67W6X_Network_Driver component |
| [MW] ST67W6X_Network_Driver | Core and API System, Wi-Fi®, Network, HTTP and FOTA components Util/Logging: Utility to process shell and trace messages onto the UART interface (can be changed by ITM) |
| [MW] FreeRTOS | FreeRTOS kernel source |
| [Utility] lpm | Tiny Low-Power Management |
| [Toolchain] Startup | Int_vect, init routines, init table, CSTACK and HEAP |
| [Toolchain] EWARM Libraries | Native compiler libraries |
These values depend on the chosen toolset and they can change in next releases.
3.6.1. ROM/flash memory footprint
The picture below shows the sum of the read only memory (flash) of the FOTA application.
The picture below shows the middleware ST67W6X_Network_Driver read-only memory (flash) used by the FOTA application.
3.6.2. Read/write (RW) memory footprint
The picture below shows only the sum of the static read/write memory (static RAM) of the FOTA application.
