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

[BertrandM]

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?

[OliM]

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.

[Alan PORTE]

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

[RMoessner]

Hi Alan and OliM,

We are sorry for the delay. Bertrand is on holiday, so I’m replacing him.

Thanks for your feedback. We have been working on your suggestions.

First, on our custom application, after moving to FUS v2.2.0, the FUS_GET_VERSION command stopped responding.

This is what led us to move away from our application and use the STM32WB-FUS-Command-Line-Interface example that you are also using for your reproduction.

We then started from this application and progressively removed some initialization code in order to understand which initialization was missing in our application. After some tests, we observed the following behavior.

On both our custom board and the P-NUCLEO-WB55, STM32CubeProgrammer now reports the FUS version as:

FUS v0.0.0

The important point is that we did not perform any FUS firmware upgrade or FUS write operation during these tests. We were only modifying the M4 application, removing some initialization code, and observing the behavior.

So we are trying to understand how we can end up with a FUS reported as 0.0.0 simply by running an M4 application with some initialization removed.

In an attempt to reinitialize the board, we also tried the RDP sequence: AA -> BB -> AA to force an erase/recovery, but this did not restore the FUS information in STM32CubeProgrammer.

We also tried to recover our boards by following the different topics and procedures described on the ST Community, but without better results. Bertrand did observe one time that the Nucleo started working again without any particular intervention, but we were not able to reproduce this behavior.

At this point, we have the same situation on two boards: one P-NUCLEO-WB55 and one custom STM32WB55 board, both reporting FUS 0.0.0.

There is also an important constraint in our project: the code we are developing needs to run in the immutable bootloader area. This means that the available flash space is very limited, and we need to save as much space as possible by reimplementing the communication APIs rather than using the full existing implementation.

This is also why we need to understand precisely which initialization steps are actually required for FUS communication to work, while ensuring that we do not corrupt or otherwise affect the FUS.

Do you have a procedure to verify whether the M0+ is still running correctly and whether the FUS is actually present and functional?

Our main concern is that we don't understand how the M0+ could have become apparently unusable without performing any FUS write operation.

Any diagnostic or recovery procedure you can provide would be very helpful.

Best regards,