Skip to main content
Associate
June 11, 2026
Question

FUS Firmware upgrade by M4 user application (using IPCC channel)

  • June 11, 2026
  • 2 replies
  • 107 views

Hi,

 

I have a custom board with a STM32WB55RG and I’m trying to upgrade the Wireless stack (and the FUS firmware) from a user application (and so without using STM32CubeProgrammer).

I'm following the Application Note AN5185.

The current FUS version is v1.2.0 and I try to upgrade the stm32wb5x_BLE_Stack_full_fw firmware (v1.14.1 or v1.15 or v1.16).

I'm able to send the FUS_GET_STATE command and it returns successfully:

  • the response (HCI command complete event packet) is well formatted, Num HCI is 0xFF, Cmd opcode is 0xFC52 (FUS_STATE) and FUS State value is 0x00 (FUS_STATE_IDLE).

I'm also able to send the FUS_FW_DELETE commands:

  • Response command opcode is 0xFC55 (FW_DELETE_STATE), status value is 0x00 (Operation started).
  • Before the delete, SFSA was 0xCE and after complete, the SFSA is 0xf4
  • Read FUS Infos from STM32CubeProgrammer shows valid STACKS version/address before and v0.0.0.0/NA after the delete.

→ The communication to the FUS though IPCC looks to work as expected for the get state and delete operations.

 

But, it doesn't work as expected when I send the FS_FW_UPGRADE command:

  • The firmware is written to the flash memory at address 0x080CE000 (I checked using STM32CubeProgrammer "Compare memory with file" the validity of the firmware in flash memory) then the FS_FW_UPGRADE command is sent.
  • The command response is valid, the status value is 0x00
  • The system resets automatically (performed by the FUS).
  • After the reset FUS_GET_STATE commands returns FUS_IDLE with FUS_STATE_NO_ERROR.
  • The SFSA is updated (0xCE while it was 0xF4 before the upgrade).
  • The flash memory at address 0x080CE000 cannot be read by STM32CubeProgrammer (as it's now is the secure area of the flash memory).

BUT:

  • The STACK version is still v0.0.0.0 and STACK address is still NA (read from STM32CubeProgrammer)
  • The device information table returns stack version 0x00000000

 

 

Is there a way to know why the FUS doesn’t fully upgrade the Wireless stack?

Any ideas to understand this behavior?

2 replies

OliM
Senior II
June 17, 2026

I am mainly following this to thread learn something for my own tries on the topic which are still todo, but one idea:
What state does SHCI_SUB_EVT_CODE_READY give as a response (can be WIRELESS_FW_RUNNING = 0x00, FUS_FW_RUNNING = 0x01,NVM_BACKUP_RUNNING = 0x10,VM_RESTORE_RUNNING = 0x11)? 

Maybe you now just need to actually start the stack through SHCI_C2_FUS_StartWs.

 

Also out of curiosity: Do you do the FwUpgrade with an arbitrary fw_src_add? I think I remember to have read somewhere, that non zero values did not actually work and/or a specific base address depending on the image size was mandatory.

ST Employee
July 16, 2026

Hi BertrandM,

 

Thank you for posting in the ST Community.

So far, I have not been able to reproduce the issue you described.

Here my setup:

  • P-Nucleo-WB55 (hardware: MB1355C-02, STM32WB55RGV6U revision Y)
  • FUS v1.2.0.0
  • STM32CubeProgrammer v2.22.0
  • Project STM32WB-FUS-Command-Line-Interface
  • STM32CubeIDE v2.2.0
  • The project is a bit old and a previous version of GNU is needed (I'm using v10.3)
  • I have tested update for stm32wb5x_BLE_Stack_full_fw.bin (from STM32CubeWB v1.13.1 / v1.15.0 / 1.16.0 / v1.17.0)
  • the BLE_Full wireless stack image is loaded at optimal address 0x080CE000

 

With this simple project/setup, I'm able to get a correct Device Info Table (with consistent version of Wireless stack).

Here the screenshot of the Device Info Table:

 

 

Here few questions/recommendations:

1) As mentioned by OliM, are you calling FUS_FwUpgrade command with 0 arguments?

SHCI_C2_FUS_FwUpgrade(0,0);

 

2) Don’t hesitate to have a look on the project I’m using:

https://github.com/stm32-hotspot/STM32WB-FUS-Command-Line-Interface

Otherwise, please consider to share with me your code (even partially, just the Wireless Stack update part).

 

3) Are you observing similar results when updating the stack directly with STM32CubeProgrammer (embedded bootloader or SWD)?

4) In your case, is BLE operational even with invalid Device Info Table?

5) Did you try to move to latest (and recommended) version of FUS v2.2.0?

Best Regards,
Alan