SHCI_C2_FUS_FwUpgrade usage

[APort]

Hello,

We have an issue updating the stack programmatically.

Following the AN5185 (section 2.1) we put the new stack binary (stm32wb5x_BLE_Stack_full_fw_1.13.1.bin) at 0x0809A000 - 45 sectors before 0x080C7000 (stack start for 1mb model) - trying to upgrade from 1.13.0.

Reset to FUS - worked alright. SHCI_C2_FUS_GetState == FUS_STATE_VALUE_IDLE

Issued SHCI_C2_FUS_FwUpgrade - no error return code.

The SHCI_C2_FUS_GetState afterwards gets FUS_STATE_ERROR_AUTH_TAG_ST_NOTFOUND and the flash content is reset (ffffffff)

1) Apparently the SHCI_C2_FUS_FwUpgrade parameters make no difference as it is all hardcoded - is this true? We would love to load it from other flash address.

2) Does the FUS on its side uses the memory at 0x20000000? If so, how?

I was looking at OTA example and it seems to holding there its state between resets but not sure about FUS side.

3) Is there something missing here?

Thanks in advance

[Remi QUINTIN]

1)Apparently the SHCI_C2_FUS_FwUpgrade parameters make no difference as it is all hardcoded - is this true?  => NO! parameters cannot be hardcoded as the size of the wireless FW varies depending on its type (full, light, Mesh, Zigbee or Thread, dual...) and version.

2) The FUS uses SRAM to store its state + additional data like its version ...

It uses a dedicated space in SRAM2a and SRAM2b, and a shared space in SRAM2a (shared tables).

In fact this data is part of the DIT (Digital Information Table) located in SRAM2a staring at 0x20000000 + IPCCDBA (IPCC mailbox data buffer base address) offset.

[APort]

1) I've meant that SHCI_C2_FUS_FwUpgrade(fw_src_add, fw_dest_add) takes two arguments but those are not used (apparently) and explicit addressing logic is used instead. This is what I'm trying figure out.

2) The 0x20000000 is SRAM base and not the address of the IPCC tables (SRAM2a/b).

The first 4 bytes are reserved (by all linker scripts) and used by BLE_Ota example only.

I'm trying to understant if FUS uses it on the other side, or it is hack for BLE_Ota only.

[Remi QUINTIN]

OK! Got your point.

Indeed the FUS is not using the source address (nor the destination address) as it looks for some magic word starting from the beginning of the Flash memory. Once found, the FUS set the SFSA option at the current sector and starts to decrypt the FW and install it at the same address it was downloaded. Once installed and integrity checked, The FUS returned to idle state. So the source address = the destination address considering the installation procedure.

Indeed SRAM2B is starting at 0x20030000 (not 0x20000000).

I dont know/think FUS is using the first bytes at 0x20000000. need to check this.

[AME MCU Support Center JT]

This example posted on STM32 Hotspot: https://github.com/stm32-hotspot/STM32WB-FUS-Command-Line-Interface

shows how to interact with FUS using FUS commands in order to perform some actions upgrading the current Wireless Stack or FUS: 

Delete the installed Wireless Stack

Switch between FUS and Wireless Stack

[APort]

Thanks, it is clear now, combined with the AN5185 update for address calculation.

A question tho, why not implementing the source address for SHCI_C2_FUS_FwUpgrade(0,0)?

It can be the source and the size, instead of the destination (I understand why you don't want to allow dest changes).

It defiantly would make the process self contained and more flexible.

Thanks, Alex.