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 is firmware 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
- 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 (fixed location in secure flash, must not be modified or removed)
- Authentication key (fixed location in secure flash, 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, keys, 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, FUS or keys).
2.2. Resources
CPU Core
FUS runs exclusively on the CM0+ core.
The boot address of CM0+ must be 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, 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 Safeboot may be running on the CM0+ core.
The address mapping for each module for an STM32WB5x is as follows:
| Module | Start Address | Size | Comments |
|---|---|---|---|
| FUS | 0x080F4000 | 24 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 "Device info table" address. The device information table contains the FUS version at offset 0xC, which is encoded on four bytes. Typically, if IPCCDBA=0x0000 and @0x20030000 contains 0x20030024, then the FUS version is @0x20030030. Installation of an FUS image must follow the conditions stated in the 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).
It is possible to read the FUS version only while it is running, and to ensure that the FUS is running correctly we can send 2 GET_FUS_STATE commands. In order to read the FUS version follow these steps on STM32CubeProgrammer:
- Connect (Mode: Normal, Reset Mode: Hardware reset)
- Start FUS
- Disconnect
- Reconnect (Mode: Hot Plug, Reset Mode: Hardware reset)
- Read memory
3.2. STM2WB5x 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. |
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). 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_V1.2.0_for_V0.5.3.bin: upgrades from FUS version V0.5.3
| Upgrade to -> from | V0.5.3 | V1.0.2 | V1.1.0 | V1.1.1 | V1.1.2 | V1.2.0 |
|---|---|---|---|---|---|---|
| V.0.5.3 | X | ✔ | X | X | X | ✔ |
| V.1.0.2 | X | X | ✔ | X | ✔ | ✔ |
| V.1.1.0 | X | X | X* | X | ✔** | ✔ |
| V.1.1.1 | X | X | X | X | ✔ | ✔ |
| V.1.1.2 | X | X | X | X | ✔ | ✔ |
| V.1.2.0 | X | X | X | X | X | ✔ |
Legend:
• X: Cannot upgrade
• √: Upgradable
• *: Must not upgrade, otherwise encryption keys are lost
• **: Upgradable but a Bluetooth® LE stack needs to be installed first and anti-rollback enabled
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 | ✔ | ✔ |
Legend:
• X: Not available
• √: Available
3.4. Differences between STM32WB5x and STM32WB1x
| Item | STM32WB5x | STM32WB1x |
|---|---|---|
| Sector size | 4 Kbytes | 2 Kbytes |
| SRAM2a start address | 0x20030000 | 0x20003000 |
| SRAM2a size | 32 Kbytes | 24 Kbytes |
| SRAM2b start address | 0x20038000 | 0x2000B000 |
| SRAM2b size | 32 Kbytes | 12 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 |
| Interface that can be used to communicate with FUS | System Bootloader USB DFU System Bootloader USART SWD (FUS Operator) |
USART SWD (FUS_Operator) |
| UFB banks address | BANK1: 0x080FB000 BANK2: 0x080FC000 |
BANK1: 0x0804C000 BANK2: 0x0804C800 |
| CKS feature | YES | NO |
- Expect FUS V0.5.3 where SFSA is 0xF6
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
- Check the value of the SBRV option bytes:
- If it is 0x3D800 (for FUS V0.5.3) or 0x3D000 (for FUS V1.x.z) then FUS is running – if it is different
from 0x3D800 (for FUS V0.5.3) and from 0x3D000 (for FUS V1.x.z) then FUS is not running - Send a wireless stack command:
- If it is acknowledged, then FUS is not running
- If it is not acknowledged, then FUS is 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” ◦ 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
Interfaces that can be used to communicate with FUS are:
- System bootloader (USB DFU and USART): provides ready-to-use commands
- SWD (FUS_Opeartor): provided by ST inside the STM32CubeProgrammer tool and offers ready-to-use commands.
- Userapplication on CM4: can be developed by the user based on STM32WB CubeFW examples (and in the future using Open Bootloader integrating FUS_Operator)
4.2. 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 tack. The number of system resets depends on the configuration and the location of the new and old images.
FUS identifies the image as an FUS upgrade image, and launches the FUS upgrade accordingly. This operation might result in a relocation of the firmware stack if it is already installed, and if the size of the new FUS is larger than the size of the current FUS. This information and any relative constraints are detailed in the FUS image release note.
The FUS upgrade requires no specific memory conditions. However, if the new FUS image size is larger than the existing FUS size, the upgrade may result in the wireless stack being moved lower in flash memory, in order to grant sufficient space for the FUS upgrade. This means that:
- Less flash memory is available for the Cortex®-M4 user application.
- The wireless stack is moved from its current address to another address defined by FUS.
- If user code is written in the sectors neighboring wireless stack start sector, there is a risk of it being erased during this operation.
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.
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. |
| 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? |
You are advised to delete the wireless stack before performing the FUS upgrade in general, and especially when upgrading from FUS V0.5.3. If the existing FUS version is higher than V0.5.3 it is not mandatory to perform the wireless stack deletion. |
| 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 binary 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. |
| 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). |