1. What is firmware upgrade services (FUS)?
FUS (firmware upgrade services) is firmware that runs on the STM32WB Cortex®-M0+, and which offers multiple features to the user.
FUS is programmed by ST on all STM32WB devices, and can be upgraded by the user.
The AN5185 is the main reference document for FUS-related subjects.
FUS features :
- Install, upgrade or delete the STM32WB Cortex®-M0+ wireless stack: Only possible if encrypted and signed by STMicroelectronics. Optionally, the upgrade can be additionally double-signed by the customer if necessary.
- FUS self-upgrade: Only possible if encrypted and signed by STMicroelectronics, Optionally, additionally the upgrade can be double-signed by the customer if necessary.
- Customer authentication key management: Used for double signature of images, install, update and locking the customer authentication key.
- User key management: Load and store customer keys (simple clear key & encrypted key by a master key) in secure area accessible only by Cortex®-M0+ code.
- Write stored key (simple or encrypted) into AES1 (advanced encryption standard) in secure mode.
- Lock a stored key to prevent its use until next system reset.
- Unload a previously loaded key from AES to prevent its use by other applications.
- Communication with Cortex®-M4 (FUS operator or bootloader): Through IPCC commands and response model, Commands already supported by STM32WB bootloader (in ROM) and FUSOperator (in User FLASH).
Acronyms definitions
| Acronym | Definition |
|---|---|
| FUS | Firmware upgrade services |
| WS | Wireless stack |
| UFB | Unique firmware boot entry |
| Safeboot | Safeboot module |
| IPCC | Inter-processor communication controller |
2. How FUS works
2.1. Context
FUS firmware is located in the secure flash memory of the STM32WB, mainly allowing update of the wireless stack located in the same memory. It can be run only by CM0, and offers a defined level of protection and authentication for the wireless stack upgrade.
When the STM32WBxx leaves ST’s production site, it has FUS (and its necessary components) programmed, but the Wireless Stack is not programmed. It has to be programmed in the field by customer, using FUS services (communication used may be bootloader, JTAG, or a user application (local loader).
FUS does not have direct external communication; it uses a mailbox to receive service requests. In addition to allowing wireless stack upgrade, it also allows additional services related to key management.
The UFB is a nonvolatile memory (NVM) space used to store the FUS state machine.
SafeBoot is code allowing management of cases where option bytes are corrupted. It allows the option bytes to be restored, and boot on the right part of the CM0 code (FUS or wireless stack).
FUS uses following resources:
- CPU2: CM0+
- Secure flash memory and option bytes
- 2 banks allocated for FUS code
- UFB for storing FUS state machine
- CKS Key storage allocated space
- Secure part of SRAM2b + Secure part of SRAM2a (if no other option)
- Interrupts
- RCC and power
- AES (secure part)
- ST symmetric key
- Authentication key (can be modified by user request or locked)
- FUS uses the following interfaces to communicate with outside:
- Non-secure part of SRAM2a
- Mailbox IPCC (coupled with shared SRAM)
- Image headers (wireless stack, FUS image)
- Non-secure part of SRAM2a
The FUS firmware parses the user flash (non-secure) or shared SRAM to identify and extract upgrade images requested by the user (upgrade of the wireless stack or FUS). It can also receive commands from the user application to perform different tasks, such as updating CKS key.
2.2. Resources
CPU Core
FUS runs exclusively on the CM0+ core.
The boot address of CM0+ is configured to the FUS start address in order to start the FUS services. This setting is done through option bytes (SBRV: secure boot reset vector, the M0+ boot address), and requires a system reset to be effective. This operation can be done only by code running on CM0+ (i.e. wireless stack, SafeBoot, or configured from production).
Flash mapping
The flash memory is shared between CM4 and CM0+.
CM0+ allocates a secure area from flash memory that is dedicated for CM0+ execution and cannot be accessed by any CM4 code. CM0+ can access, in read/write, all the flash memory (secure and non-secure).
The secure flash boundary is defined by secure option bytes and can only be set by code running on CM0+.
Only FUS, wireless stack or Safe boot may be running on the CM0+ core.
The address mapping for each module for an STM32WBx is as follows:
| Device | Module | Start Address | Size | Comments |
|---|---|---|---|---|
| STM32WB5x\WB3x | FUS | 0x080F4000 | 24 Kbytes | - |
| STM32WB1x | FUS | 0x08046000 | 24 Kbytes | - |
SRAM2 mapping
The secured SRAM2 for STM32WBx devices with FUS v2.2.0 and running in "FUS mode" is partitioned as follow:
| Device | Module | SRAM2 Private Start Address | SRAM2a | Secure Size | SRAM2b | Secure Size | Comments |
|---|---|---|---|---|---|---|---|
| STM32WB5x\WB3x | FUS | 0x2003C000 | non secure | 0 Kbytes | secure | 16 Kbytes | - |
| STM32WB1x | FUS | 0x20036800 | secure | 6 Kbytes | secure | 4 Kbytes | - |
3. FUS versioning and identification
3.1. FUS identification
The user must read the shared table memory in SRAM2a to identify the FUS version. The first word in SRAM2a, pointed to by the IPCCDBA Option Bytes, is the address of the "Device info table".
In " FUS running" mode, this table contains the FUS version at offset 0xC and the Safeboot version at offset 0x8 which are encoded on four bytes. Typically, if IPCCDBA=0x0000, then the default SRAM2a address should be considered and if @0x20030000 contains 0x20030024, then the FUS version is @0x20030030 (and the Safeboot version is @0x2003002C).
In " Stack running" mode, this table contains the FUS version at offset 0x4 which is encoded on four bytes. Typically, if IPCCDBA=0x0000, then the default SRAM2a address should be considered and if @0x20030000 contains 0x20030024, then the FUS version is @0x20030028.
Note that the installation of an upgraded FUS image must follow the conditions stated in the coprocessor image binary release notes.
When using the SWD interface:
- With STM32CubeProgrammer versions older than V2.7.0, the address of the device information table is located at 0x20030890.
- With STM32CubeProgrammer V2.7.0 and higher, the device information table is located at 0x20030024 (the device must be connected under Hot Plug mode).
Under STM32CubeProgrammer, it can be read the FUS version in the FUS information section when the FUS is running. To switch to FUS running mode, you can send two "GET_FUS_STATE" commands, which can be simply done by pressing the "Start FUS" button. This FUS command can also be used to get the FUS status and return the error code when the FUS State Value is 0xFF.
In order to read the FUS version using STM32CubeProgrammer, follow these steps:
- Connect (Mode: Normal, Reset Mode: Hardware reset)
- Start FUS
- Disconnect
- Reconnect (Mode: Hot Plug, Reset Mode: Hardware reset)
- Read memory as above (or Read FUS infos)
3.2. STM32WB5x FUS versions
Note that FUS is programmed by STMicroelectronics on all STM32WB devices, and that it can be upgraded by the user in the field.
| FUS version | Description |
|---|---|
| V0.5.3 | Default version programmed in production for all STM32WB5xx devices. Must be upgraded to V1.0.1 on STM32WB5xG devices or to V1.0.2 on STM32WB5xE/5xC devices. This version is not available for download on www.st.com and cannot be installed by users. |
| V1.0.1 | First official release available on www.st.com and dedicated to STM32WB5xG devices only (1 Mbyte flash memory size). This version must not be installed on STM32WB5xE/5xC devices, otherwise the device enters a locked state and no further updates are possible. |
| V1.0.2 | First official release available on www.st.com and dedicated to STM32WB5xE/5xC devices (512 Kbyte and 256 Kbytes flash memory size). Use the V1.0.2 on STM32WB5xG devices if the devices present FUS V0.5.3. If an STM32WB5xG device has FUS V1.0.1, there is no need to upgrade to V1.0.2, since it does not bring any new feature/change versus V1.0.1. In the event that FUS V1.0.2 installation is started by the user on an STM32WB5xG device with FUS V1.0.1, FUS returns FUS_STATE_IMG_NOT_AUTHENTIC error, and discards the upgrade. |
| V1.1.0 | FUS update to support the following features:
Installing FUS V1.1.0 over an FUS V0.5.3 installation results in an FUS_STATE_IMAGE_NOT_AUTHENTIC error and discarding of the upgrade. |
| V1.1.1 | Add management of 640 Kbyte parts, fully compatible with V1.1.0 |
| V1.1.2 | FUS update to:
|
| V1.2.0 | FUS update to:
|
| V1.2.0 RC2 | Add Safeboot security enhancement, no changes to FUS features. |
| V2.0.0 |
|
| V2.1.0 | FUS update to:
|
| V2.2.0 | FUS update to:
|
3.3. FUS version compatibility
The table below details the FUS version compatibility options (when it is possible to upgrade from one version to another).
The FUSv2 upgrade incremental process is described in Release Notes for STM32WB Copro Wireless Binaries using STM32CubeProgrammer GUI (version v2.20x) or CLI through ST-link or USB connection according to WB5x/Wb3x/WB1x device specifications.
This recommendation applies only to the first upgrade from FUS v1.2. Once Safeboot v2.0.1 has been installed, it does not need to be reinstalled for subsequent FUS updates (for example, upgrading FUS v2.0 to FUS v2.2 does not require an additional Safeboot v2.0.1 update).
Main FUSv2 upgrade steps consist for STM32WB5x (as example) to :
| FUSv2 upgrade incremental process | Starting point device | Action |
| FUSv0.5.3 | => Must be updated first to FUSv1.2.0 installing: [stm32wb5x_FUS_fw_for_fus_0_5_3.bin] | |
| FUSv1.x.y
(when x < 2) |
=> Must be updated first to FUSv1.2.0 installing: [stm32wb5x_FUS_fw_1_2_0.bin] | |
| FUSv1.2.0 | => Must be updated to latest FUSv2 installing: [stm32wb5x_FUS_fw.bin] | |
| FUSv2 (v2.2.0) | => Up to date, ready to download the new Wireless Stack binary (or safeboot binary [stm32wb5x_FUS_fw.bin]) |
FUS V1.2.0 is the version that allows the upgrade from any previous version. It is released in two binaries:
• stm32wb5x_FUS_fw_V1.2.0.bin : for upgrades from any FUS version V1.x.y
• stm32wb5x_FUS_fw_for_V0.5.3.bin: for upgrades from FUS version V0.5.3
Then FUS V2 can be upgraded from FUS V1.2.0 version.
• stm32wb5x_FUS_fw.bin : for upgrades from FUS V1.2.0
| Upgrade to:
from below: |
V0.5.3 | V1.0.2 | V1.1.0 | V1.1.1 | V1.1.2 | V1.2.0 | V2.0.0 | V2.1.0 | V2.2.0 |
|---|---|---|---|---|---|---|---|---|---|
| V.0.5.3(*) | X | ✔ | X | X | X | ✔(2) | X(1) | X(1) | X(1) |
| V.1.0.2(*) | X | X | ✔ | X | ✔ | ✔ | X(2) | X(2) | X(2) |
| V.1.1.0(*) | X | X | X* | X | ✔(1) | ✔ | X(2) | X(2) | X(2) |
| V.1.1.1(*) | X | X | X | X | ✔ | ✔ | X(2) | X(2) | X(2) |
| V.1.1.2(*) | X | X | X | X | ✔ | ✔ | X(2) | X(2) | X(2) |
| V.1.2.0 | X | X | X | X | X | ✔ | ✔ | ✔ | ✔ |
| V.2.0.0 | X | X | X | X | X | X | ✔ | ✔ | ✔ |
| V.2.1.0 | X | X | X | X | X | X | X | ✔ | ✔ |
| V.2.2.0 | X | X | X | X | X | X | X | X | ✔ |
Legend:
• ✔: Upgradable
• ✔(1): Upgradable but a Bluetooth® Low Energy stack needs to be installed first and enables Anti-rollback
• ✔(2): Upgradable with dedicated FUS v1.2.0 binary version for FUS v0.5.3
• X: Cannot upgrade (mainly due to FUS anti-rollback).
• X*: Must not be upgraded; otherwise, the encryption keys will be lost.
• X(1): Not directly upgradable; upgrade to FUS v1.2.0 first (using dedicated binary for FUS v0.5.3)
• X(2): Not directly upgradable; upgrade to FUS v1.2.0 first
• (*) Not available on STM32WB1x
FUS version availability
FUS version availability is be summarized in the table below:
| FUS version | Production | Binary on www.st.com |
|---|---|---|
| V.0.5.3 | ✔ | X |
| V.1.0.2 | ✔ | ✔ |
| V.1.1.0 | ✔ | ✔ |
| V.1.1.1 | ✔ | X |
| V.1.1.2 | X | ✔ |
| V.1.2.0 | ✔ | ✔ |
| V.2.0.0 | X | ✔ |
| V.2.1.0 | X | ✔ |
| V.2.2.0 | ✔ | ✔ |
Legend:
• X: Not available
• √: Available
3.4. Main differences between STM32WB5x and STM32WB1x with FUSv2
| Item | STM32WB5x | STM32WB1x |
|---|---|---|
| Sector size | 4 Kbytes | 2 Kbytes |
| SRAM2a start address | 0x20030000 | 0x20030000 |
| SRAM2a size | 32 Kbytes | 32 Kbytes |
| SRAM2b start address | 0x20038000 | 0x20038000 |
| SRAM2b size | 32 Kbytes | 4 Kbytes |
| FUS start address | 0x080F4000 | 0x08046000 |
| SBRV by default (FUS running) |
0x3D000 | 0x11800 |
| SFSA by default (FUS running and no stack installed) |
0xF4* | 0x8C** |
| FUS version address | 0x20030030 | 0x20003030 |
| Ext. Interface that can be used to communicate with FUS | System Bootloader USB DFU System Bootloader USART SWD (FUS Operator) |
USART SWD (FUS_Operator) |
| Int. Interface that can be used to communicate with FUS | IPCC (M4 appli) | IPCC (M4 appli) |
| UFB banks address | BANK1: 0x080FB000 BANK2: 0x080FC000 |
BANK1: 0x0804C000 BANK2: 0x0804C800 |
| CKS feature | YES | NO |
* Expect FUS V0.5.3 where SFSA is 0xF6; when FUSv2x with 16kB NVM data area then SFSA is 0xF0 for STM32WB5xxG(1M); note that default SFSA value may vary between STM32WB flash size derivatives
** when FUSv2x with 16kB NVM data area then SFSA is 0x84 for STM32WB1x
4. FUS activation and upgrade
4.1. FUS activation
FUS runs on the Cortex®-M0+ and on the protected flash memory zone dedicated for FUS and wireless stack. There are two possible situations:
| Situation | How to activate FUS |
|---|---|
| No wireless stack is running (for example the first time the STM32WB Series device is running, or the wireless stack has been removed) |
Ensure the Cortex®M0+ is activated by setting the C2BOOT bit in the PWR_CR4 register. Ensure that IPCCDBA (option byte) points to a valid shared table information structure in SRAM2a (enter correct pointers in the device information and system tables). Note: Both of these conditions are performed automatically by the system bootloader. Hence device boot is configured on system memory, and FUS must be activated with no need for further user actions. Otherwise, these actions must be performed by user code running on the Cortex®-M4 CPU. |
| Wireless stack is installed and running | Perform the same steps as above request wireless stack to launch FUS by sending two consecutive FUS_GET_STATE commands. The first one must return FUS_STATE_NOT_RUNNING state and the second causes FUS to start. |
In order to check if FUS is running or not, the following options are available:
- Send a single FUS_GET_STATE command and check the return status
- If the return status is FUS_STATE_NOT_RUNNING then FUS is not running
- If the return status is FUS_STATE_NOT_RUNNING then FUS is not running
- Check the value of the SBRV option bytes:
- On STM32WB5x as example: If it is 0x3D800 (for FUS V0.5.3) or 0x3D000 (for FUS V1.x.z or FUSv2) then FUS is running – if it is different
from 0x3D800 (for FUS V0.5.3) and from 0x3D000 (for FUS V1.x.z or FUSv2) then FUS is not running
- On STM32WB5x as example: If it is 0x3D800 (for FUS V0.5.3) or 0x3D000 (for FUS V1.x.z or FUSv2) then FUS is running – if it is different
- Send a wireless stack command:
- If it is acknowledged, then FUS is not running
- If it is not acknowledged, then FUS is running
- If it is acknowledged, then FUS is not running
- Read the shared table information:
- Read IPCCDBA (in option bytes) to get the shared tables' start address in SRAM2a – get the device information table address
- Read the field “Last FUS active state” at offset 0x5, then if you get 0x04 means that the stack is running ◦ Other values mean that FUS is running
- Read the "Async Ready" event that is sent by FUS at startup
Different interfaces that can be used to communicate with FUS are:
- System bootloader (via USB DFU and USART): provides ready-to-use commands
- FUS_Operator (via SWD): provided by ST inside the STM32CubeProgrammer tool and offers ready-to-use commands.
- User application on CM4 (via IPCC): can be developed by the user based on STM32WB CubeFW examples (and in the future using Open Bootloader integrating FUS_Operator)
Note that you can find an example of STM32WB FUS Command Line Interface (FUS CLI) on ST hotspot at:https://github.com/stm32-hotspot/STM32WB-FUS-Command-Line-Interface
4.2. STM32CubeProgrammer tool update
The STM32CubeProgrammer >= v2.20x under “Firmware Upgrade Services” will have a simplified interface
with only 2 options for FW upgrade to be fully compliant with FUSv2 new features,:
- “Auto mode” with automatic start address computation or “manual mode” with Start Address to enter and pop-up msg
- “verify download” option as before
and a new “Stack address” box (on right) equal to SBRV address after Wireless stack install
4.3. FUS self-upgrade
FUS is capable of self-upgrade in the same way as wireless stack upgrade. Deleting FUS is not possible.
In order to perform an FUS upgrade, perform the following steps:
- Download the FUS image from www.st.com or from the STM32CubeMx repository.
- Write the FUS image into the user flash memory at the address indicated in the FUS image directory Release_Notes.html file.
- Ensure FUS is running.
- Send the FUS_FW_UPGRADE command through the IPCC mechanism (as explained in the sections below).
- Send the FUS_GET_STATE command until a state equal to FUS_STATE_NOT_RUNNING is returned (this means that the wireless stack has been installed and is now running).
During the installation process, expect multiple system resets to occur. These system resets are performed by FUS and are necessary for the modification of dedicated memory parameters, and to make the Cortex®-M0+ run the installed wireless stack. The number of system resets depends on the configuration and the location of the new and old images.
The FUS identifies the image as an FUS upgrade image and initiates the FUS upgrade accordingly. The FUS size is fixed at 24 kB, with the flash start address remaining unchanged.
Note If user code is written in the sectors neighboring wireless stack start sector, there is a risk of it being erased during this FUS upgrade operation as a FUS copy has to be done below stack wireless.
The size of the FUS and results of its upgrade are detailed in its Release_Notes.html file. The image start address must be aligned to a sector start (i.e. multiple of 4 Kbytes) and the image size must be a multiple of 4 bytes, otherwise, FUS rejects the installation procedure.
FUSv2 main features
4.4. FUSv2 context
These new FUS v2 features mainly concern:
• Robustness enhancements: addressing detected security vulnerabilities and known weakness against asynchronous reset, with improvements in stack installation when only 1 sector difference
• BLE Pairing/bonding data preservation: ensuring NVM data preservation during FW Upgrades.
• Retro-compatibility: supporting all FUS commands and allowing installation of all types of Coprocessor binaries (ie legacy or new format) with the new FUSv2.
• Support New Safeboot binary (v2.0.1) with added Robustness enhancements to reset device with factory settings in case of HW Option Bytes corruption.
• FUSv2 upgrade required to support new BLE features with new stack format
4.5. FUSv2 new features vs previous FUSv1.2
4.6. Safeboot behavior overview
The safeboot aims to restore the device to factory settings in case of hardware Option Bytes corruption. As reminder, after the FUSv2 upgrade it is highly recommended to update Safeboot to v2.0.1, which includes robustness enhancements.
When activated, the Safeboot code will perform following main steps:
- Reset the UFB (User Flash Block) erasing flash pages
- Mass erase of user flash from page 0 up to flash boundary
- Clear Option byte error flags
- Program Option bytes and security configuration with default factory settings
- CPU2 Ready to reboot in FUS mode (after system reset)
4.7. some "typical use cases" with FUSv2
4.7.1. FUS upgrade (FUSv1.2 to FUSv2)
Here is an example of FUSv2 upgrade from FUSv1.2 on STM32WB5x :
•On left figure: FUSv2 image is flashed with STM32CubeProgrammer below installed stack (or any WS NVM data section), then FUSv1.2 will decrypt FUSv2 image and device reboot on FUSv2 (on new SBRV)
• On right figure: last stage, FUSv2 will copy itself to its final location @0xF4000 and reboot device (on last SBRV)
4.7.2. BLE stack update (with NVM data migration)
Here is an example of FW update (Legacy to New) with NVM data migration with FUSv2 on STM32WB5x:
•On left figure: Interleaved BLE NVM data section from legacy stack (+0x1000 offset) is migrated in 16kB reserved area (below FUS@0xF4000 as defined in FW stack footer) when FW update done by FUSv2
•On right figure: after new stack deleted by FUSv2, new copied NVM data section is kept in secure flash area (between 0xF0000 and 0xF4000 on 4 sectors for Dory_1M)
4.7.3. typical "New format" stack update
Here is an example of FW update (New to New) with FUSv2 on STM32WB5x:
•On left figure: in reserved section 16kB, the BLE NVM data are preserved when new FW update
installed by FUSv2 (below 0xF0000)
•On right figure: after new stack deleted by FUSv2, NVM data section still kept in secure flash area
4.7.4. SafeBoot update
Here is an example of SafeBoot v2.0.1 update on STM32WB5x:
•SafeBoot binary is flashed with STM32CubeProgrammer below NVM data section (when no stack installed) then FUSv2 will decrypt and copy Safeboot binary @ 0xFF000 and delete the temporary copy.
4.8. Details about “Start address” interface settings for STM32CubeProgrammer (version >= v2.20)
The Firmware upgrade services tab in STM32CubeProgrammer is used to flash stack binaries. Since version v2.20, the interface has evolved with new option "start address automatic computation" when selected, the tool automatically compute start address (ie download address) according to current board configuration. When stack has been installed, the current stack flash address is displayed with FUS infos.
4.9. Details about FUSv2 “Start address” computation: main principles
Here are the main principles of the automatic start‑address computation, based on the current board configuration, using different Option Bytes settings and information retrieved from the stack binary to be installed.
LEGEND:
• Start Address: (eqv Download Address) is the address where the new wireless stack is loaded, aligned to sector size
• FUS_Address: is the reference FUS flash address before first install
• SFSA: is the Secure Option register value indicating the current boundary of flash memory secure area
•SFSA_Prod: is the SFSA value at production output, when no stack has been installed yet
• Sector_Size: is 4 KB for STM32WB5xxx, and 2 KB for STM32WB10xx and STM32WB15xx
• Flash_Size: is the available HW flash size in Kbytes for different flash size derivatives
• image_footer.flash_size: is the size in bytes of the stack binary to install provided in binary footer part
• image_footer.data_section_size: (eqv NvmSectionSize) is the size of the reserved NVM flash area containing stack pairing data
Depending on the stack format (legacy or new) to be installed, a first step consists in computing a value called “max_start_address”.
In a second step, depending on whether automatic or manual mode is selected (with a user‑defined given start address in manual mode), the final start address where the stack will be installed is computed. If some settings are inconsistent, error pop‑up messages are displayed.
Some device characteristics and FUS settings between different STM32WB flash derivatives:
4.10. Know limitations of previous STM32CubeProgrammer versions regarding FUSv2 compliancy
Several issues have been identified with STM32CubeProgrammer versions ≤ v1.19.x regarding FUSv2 compliance. Please update to the latest available version from the ST website: STM32CubeProg | Software - STMicroelectronics
5. FAQ
| Question | Answer |
|---|---|
| When I receive a virgin STM32WB device from ST, what does it contain exactly? | All STM32WB devices delivered by STMicroelectronics contain by default the FUS and the bootloader. They don't contain the pre-installed wireless stack. |
| I cannot read the FUS version | Accessing the device information table is possible when the following conditions are met : The device information table address is written in the location pointed to by the IPCCDBA option byte. The Cortex®-M0+ is enabled + When FUS is running on the Cortex®-M0+ (If the wireless stack is running, it is possible to force FUS to run by sending two FUS_GET_STATE commands). So, when accessing the device via SWD, it is normal to not find a valid device information table (vs FUS mapping) because it has not yet been written or the Cortex®-M0+ has not yet been enabled. That’s why it is more convenient to read the device information table when the bootloader is running, because it performs actions (1) and (2) above. Note: It is possible to connect through SWD and disable the hardware reset option (hot plug), and keep boot on the bootloader, which allows the user to read the device information table from FUS mapping. + When wireless stack is running on the Cortex®-M0+, The BLE FW M0 code is also updated a device information table with mapping slightly different but also containing FUS version and stack version (cf paragraph "FUS identification" previously). |
| I want to upgrade FUS image and I already have a wireless stack installed. Do I need to delete the wireless stack prior to upgrading FUS? |
In general, you are advised to delete the wireless stack before performing the FUS upgrade, and especially when upgrading from FUS V0.5.3. However If the existing FUS version is higher than V0.5.3 it is not mandatory to perform the wireless stack deletion (in particular with FUSv2). |
| How do I know quickly if my device is running FUS or wireless stack? | There are multiple ways to check it: Read the option bytes and check the value of SBRV. If FUS is running it is 0x3D000 (or 0x3D800 if FUS V0.5.3 is running) |
| What is the IPCCDBA option byte used for? | IPCCDBA is used to change the offset to where the the device information table is read/written. |
| After an upgrade operation, I cannot access flash memory anymore and can't communicate with FUS. | First check if SFSA=0x00. If so, this means that Safeboot has been triggered. Safeboot is triggered when an option byte corruption occurs. This may occur during an FUS upgrade operation, or during any user application operation dealing with the option bytes. |
| Is it possible to downgrade the FUS version (for example when current FUS running version is V1.0.2, is it possible to install FUS V1.0.1?) | FUS downgrade is not possible for any combination of versions. Only a later version can be installed. In the case of a downgrade tentative, FUS simply rejects the upgrade and returns an error message. |
| Does FUS erase the shadow of encrypted firmware after installation? | Yes, FUS does erase the shadow remaining sectors of the encrypted firmware after it has been installed and moved to a higher address location. |
| How can I read the FUS version from the binary? | The FUS version can be found in the FUS binary footer at address 0x00005F50. For example, for FUS V1.0.2 we can read 0x01000200 which means FUS version 1.0.2. The only exception is for FUS version V1.2.0 written in the binary as 0xFFFFFFFF. Once it is installed, it shows the correct version: V1.2.0. For FUSv2.1 as example, the version can be found in the FUS binary footer at address 0x00005F38, we can read 0x00000102 |
| After an FUS upgrade operation, the user keys can be saved? | For any FUS upgrade operation, the user keys stored by FUS are erased. |
| FUS is not responding, what can I do? | First of all check whether or not SBRV and SFSA are aligned with the FUS boot address and secure start address. Then check the Flash ECC register (error occurs due to flash corruption). Check whether CM0+ is activated or not (if activated we read 0x00008000 at address 0x5800040c). |
| I activated the anti-rollback mechanism before installing any stack, can I now install my firmware ? | The anti-rollback must be activated after installing your firmware reference (the installed stack version is used later to compare with next firmware version), because FUS does not allow (after activation of the anti-rollback) any stack update with a version lower than the stack reference version. In your case the stack reference version is considered as FFFFFFFF (while no stack installed and anti-rollback is activated), so no firmware update is allowed after that, and no recovery is possible at this point. |
| Accidentally, I got SFSA = 0x00 and SBRV= 0x3FC00 what's happened? | This is due to option byte corruption, or to supply voltage or level stability. This configuration of the SFSA/SBRV option bytes means that the STM32WB hardware forces the boot to Safeboot whatever the firmware being run. To activate Safeboot and perform a factory reset the user must activate the Cortex-M0+ by writing the value 0x00008000 to address 0x5800040C using the SWD interface. If a FUS version lower than V1.1.0 is running, then no recovery is possible at this point. |
| After two firmware upgrade operations, why are SBRV and SFSA not aligned at the same security level? | Known limitation : For FUS versions lower than V1.2.0, when you install firmware larger than other already installed firmware, SBRV and SFSA are not aligned at the end of the second install, and the device is bricked (SBRV points to the first firmware installed, which is corrupted). |
| on STM32WB5x, I got SFSA=0x0F after stack FW_delete and not SFSA=0xF4, what's going on? | This is due to 16kB of "NVM data section" which has been created by FUSv2 " new format" stack to preserve BLE pairing/bonding data. If you wan't to purge it, we can install a "legacy" format stack as BLE stack from STM32WB Cube delivery < =v1.20.0 or other ZB, thread stack |
| What happens after attempting to install FUS v1.2 on a STM32WB that is already running FUS v2.x? | Example: Let’s consider that the STM32WB5xxG (1 Mbyte) is used in this case; for other memory densities, addresses may vary accordingly.
FUS v2.2 (or generally FUS v2.x) is installed, with
This stack binary, which is Solutions: a) Perform a mass erase. or b) Erase the memory area from |