1. What is the Firmawre Upgrade Services (FUS)
FUS (Firmware Upgrade Services) is a firmware running on STM32WB Cortex®-M0+ and offering multiples features for user.
1.1. 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 (FUSOperator or bootloader):
- Through IPCC commands and response model. - Commands already supported by STM32WB bootloader (in ROM) and FUSOperator (in User FLASH).
1.2. Acronyms definitions
| Acronym | Definition |
|---|---|
| FUS | Firmware Upgrade Services |
| WS | Wireless Stack |
| UFB | Unique Firmware Boot entry |
| Safeboot | Safeboot module |
2. General Design Aspects
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
o 2x Banks allocated for FUS code
o UFB for storing FUS state machine
o 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
2.2.1. 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) 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).
2.2.2. 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 |
|---|---|---|---|
| ST Symmetric Key | 0x080FFFA0 | 256 Bits | Signle Key of 256 bits |
| Safeboot | 0x080FF000 | 4KB | 1 sector |
| UFB Bank1 | 0x080FB000 | 4KB | Includes Authentication key |
| UFB Bank2 | 0x080FC000 | 4KB | Includes Authentication key |
| User Keys | 0x080FA000 | 4KB | 125 Keys + Master Key + Keys table |
The address mapping for each module for stm32wb1x is as following:
| Module | Start Address | Size | Comments |
|---|---|---|---|
| ST Symmetric Key | 0x0804F7A0 | 256 Bits | Signle Key of 256 bits |
| Safeboot | 0x0804F000 | 2KB | 1 sector |
| UFB Bank1 | 0x0804C000 | 2KB | Includes Authentication key |
| UFB Bank2 | 0x0804C800 | 2KB | Includes Authentication key |
| User Keys | - | - | No User Keys for stm32wb1x FUS |
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.