1. What is the Firmware Upgrade Services (FUS)
FUS (Firmware Upgrade Services) is a firmware running on STM32WB Cortex®-M0+ and offering multiples features for user.
FUS is programmed by ST on all STM32WB devices and can be upgraded by user.
The AN5185 is the main reference document for FUS subject.
FUS Features :
- Install, upgrade or delete STM32WB Cortex®-M0+ wireless stack : Only encrypted and signed by STMicroelectronics, Optionally, additionally double signed by customer if needed
- FUS self-upgrade: Only encrypted and signed by STMicroelectronics, Optionally, additionally double signed by customer if needed
- Customer authentication key management: Used for images double signature, Install, update and lock the customer authentication key
- User key management: Load and Store customer keys (Simple clear key & Encrypted key by 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 usage until next system reset.
- Unload a previously loaded key from AES to prevent its usage 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 Work
2.1. Context
The FUS is a firmware located in the secure flash memory of STM32WB and allowing mainly to update the Wireless stack located in the same memory. It can be running only by CM0 and offers a defined level of protection and authentication for the wireless stack upgrade.
When STM32WBxx leaves ST’s production site, it has FUS (and its necessary components) programmed, but Wireless Stack is not programmed. It has to be programmed on the field by customer, using FUS services (communication used may be Bootloader or JTAG or user application (local loader)).
The FUS does not communicate with outside directly. It uses mailbox to get services requests. In addition to allowing Wireless Stack upgrade, it also allows additional services related to keys management.
The UFB is a nonvolatile memory (NVM) space used to store the FUS state machine.
The SafeBoot is a code allowing to manage the case when option bytes are corrupted, it allows to restore option bytes and boot on the right part of the CM0 code (FUS or wireless stack).
The FUS uses following resources:
- CPU2: CM0+
- Secure Flash Memory and options bytes
- 2x 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)
- The FUS uses following interfaces to communicate with outside:
- Non-Secure part of SRAM2a
- Mailbox IPCC (coupled with shared SRAM)
- Image headers (Wireless stack, keys, FUS image)
The FUS parses the user flash (non-secure) or shared SRAM to identify and extract upgrade images requested by user (upgrade of Wireless Stack, FUS or keys)
2.2. Resources
CPU Core
FUS runs exclusively on CM0+ core.
The boot address of the CM0+ must be configured to FUS start address in order to start 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 a code running on CM0+ (ie. Wireless stack, SafeBoot, or configure from production).
Flash mapping
The Flash memory is shared between CM4 and CM0+.
CM0+ allocates a secure area from Flash 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).
Secure Flash boundary is defined by secure option bytes and can be set only by code running on CM0+.
Only FUS or Wireless stack or Safeboot may be running on CM0+ core.
The address mapping for each module for stm32wb5x is as following:
| Module | Start Address | Size | Comments |
|---|---|---|---|
| FUS | 0x080F4000 | 24 KB |
3. FUS versioning and identification
3.1. FUS Identification
The user needs to read the shared table memory in SRAM2a to identify the FUS version. The first word in SRAM2a pointed by 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 a FUS image must follow the conditions stated in the image binary release notes
When using the SWD interface with the STM32CubeProgrammer older than V2.7.0, the address of the device information table is located at 0x20030890. For 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 FUS version only when it is running and to ensure that the FUS is correctly running we can send 2 GET_FUS_STATE commands
3.2. stm32wb5x FUS Versions
Please note that FUS is programmed by ST on all STM32WB devices and that it can be upgraded by user on 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-MBytes 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-KBytes and 256-KBytes Flash memory size) Use the V1.0.2 on the STM32WB5xG devices if the devices present FUS V0.5.3. If an STM32WB5xG device has FUS V1.0.1, then there is no need to upgrade to V1.0.2, since it does not bring any new feature/change vs. V1.0.1. In case FUS V1.0.2 installation is started by user on an STM32WB5xG device with FUS V1.0.1, FUS returns FUS_STATE_IMG_NOT_AUTHENTIC error and discard the upgrade |
| V1.1.0 | FUS update to support following features: • Add FUS_ACTIVATE_ANTIROLLBACK command that allows activating Anti-rollback on wireless stack by user. User can activate this feature in order to prevent any installation of older wireless stack. |
| V1.1.1 | Add management of 640KB parts, full compatible with V1.1.0 |
| V1.1.2 | FUS update to: • Optimize Flash usage: this allows the installation of a stack, maintaining one sector separation below a previously installed stack (instead of stack size space constraint |
| V1.2.0 | FUS update to: • Includes V1.1.2 FUS updates in production |
| V1.2.0 RC2 | Add Safeboot security enhancement, no changes on FUS features. |
3.3. FUS versions compatibility
The table below details the FUS versions compatibility options (when it is possible to upgrade from a 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 enable Anti-rollback
FUS versions availability
FUS versions availability can be resumed by 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 & STM32WB1x
| Item | stm32wb5x | stm32wb1x |
|---|---|---|
| Sector Size | 4KB | 2KB |
| SRAM2a Start address | 0x20030000 | 0x20003000 |
| SRAM2a Size | 32KB | 24KB |
| SRAM2b start address | 0x20038000 | 0x2000B000 |
| SRAM2b Size | 32KB | 12KB |
| 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
The FUS runs on 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 Cortex®-M0+ is activated by setting C2BOOT bit in PWR_CR4 register Ensure IPCCDBA (Option Bytes) points to a valid shared table information structure in SRAM2a (enter the correct pointers to device information table and system table) Note: Both of these conditions are performed automatically by system bootloader. So if device boot is configured on system memory, the FUS must be activated with no need for further user actions. Otherwise, these actions must be performed by user code running on 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 it is FUS_STATE_NOT_RUNNING then FUS is not running.
- Check the SBRV Option Bytes value:
- if it is 0x3D800 (for FUS V0.5.3) or 0x3D000 (for FUS V1.x.z) then FUS must be 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 stack must be running ◦ Other values mean that FUS must be 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): provide ready to use commands
- SWD (FUS_Opeartor): provided by ST inside the STM32CubeProgrammer tool and offers ready to use commands.
- User Application on CM4: can be developed by user based on STM32WB CubeFW examples (and in the future using Open Bootloader integrating FUS_Operator)
4.2. FUS self-Upgrade
The FUS is capable of self-upgrade in the same way as wireless stack upgrade. Deleting FUS is not possible
In order to perform a FUS upgrade, perform the following steps:
1. Download the FUS image from www.st.com or from the STM32CubeMx repository.
2. Write the FUS image in the user Flash memory at the address indicated in the FUS image directory Release_Notes.html file.
3. Ensure FUS is running.
4. Send FUS_FW_UPGRADE command through IPCC mechanism (explained in sections below).
5. Send FUS_GET_STATE till getting state equal to FUS_STATE_NOT_RUNNING (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 Cortex®-M0+ run the installed wireless tack. The number of system resets depends on the configuration and the location of new and old images.
FUS identifies the image as 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. But if the new FUS image size is larger than existing FUS size, the upgrade may result in moving the wireless stack lower in Flash memory in order to grant sufficient space for 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 a 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 (ie. 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 device information table is possible when following conditions are met : Device info table address is written in location pointed 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? |
It is 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, then, 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 IPCCDBA Option Byte used for? | IPCCDBA is used to change the offset where to read/write the device information table. |
| After an upgrade operation, I cannot access Flash memory anymore and can't communicate with FUS. | First check if SFSA=0x00. If it is the case, then it means safeboot has been triggered. Safeboot is triggered when an Option Bytes corruption occurs. This may occur during a FUS upgrade operation or during any user application operation dealing with Option Bytes. |
| Is it possible to downgrade 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 in any combination. It can be installed only forward. In case of 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 upper address. |
| How can I read FUS version from the binary? | FUS version can be found on the binary at address 0x00005F50, for example for FUS V1.0.2 we can read 0x01000200 that means FUS version 1.0.2. The only exception exists is for FUS V1.2.0 version written in the binary as 0xFFFFFFFF, once it is installed, it shows the correct version V1.2.0. |
| After FUS upgrade operation, the user keys can be saved? | For any FUS upgrade operation, user keys stored by FUS are erased. |
| FUS is not responding, what can I do? | First of all check SBRV & SFSA are aligned or not with FUS boot address and secure start address, then check the Flash ECC register (error occurs due to flash corruption), check if CM0+ is activated or not (if activated we can 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 will be used to compare with next firmware version), because the FUS will not allow (after activate the Anti-Rollback) any stack update with version lower than the stack reference version. In your case the stack reference version will be considered as FFFFFFFF (while no stack installed and Anti-Rollback is activated) so no firmware update will be 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 bytes corruption or related to voltage stability or level, this option bytes configuration (SFSA/SBRV) means that the STM32WB hardware forces the boot to Safeboot whatever the running firmware, to activate the Safeboot and perform a factory reset the user must activate the cortex-M0+ by writing the value 0x00008000 at the 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 twice firmware upgrade operation, Why SBRV and SFSA are not aligned at the same security level? | Known limitation : For FUS version lower than V1.2.0 when you install firmware larger than other already installed firmware, SBRV and SFSA will be not aligned at the end of the second install and the device will be bricked (SBRV will be pointing at the first firmware installed which is corrupted). |