How to reliably determine installed FUS version from application code?

[HRadt.1]

To bring a design to production I need to determine which FUS version is installed.

In this design I do not have access to the USB/UART Bootloader, I only have SWD and UART on alternate pins.

On a processor on which I manually installed FUS 1.1.0 I successfully read the FUS version by calling SHCI_C2_FUS_GetState twice to ensure that FUS is actually running and then reading memory location 0x20030030.

On 0.5.3 my program hangs during C2 core initialization (I can handle this, no answer is also an answer)

On 1.0.2 I get 0x00010001 as a result, which does not match the expected value of 0x01000200

On 1.1.0 I get the expected value of 0x01010000

(all values as described in STM32Cube_FW_WB_V1.7.0/Projects/STM32WB_Copro_Wireless_Binaries/STM32WB5x/Release_Notes.html)

[HRadt.1]

Additional findings:

The SHCI_GetWirelessFwInfo() method, which also seems to read FUS version, queries it from address 0x2003002C (which is different from the 0x20030030 listed in the release notes)

At least for FUS v1.0.2 the version seems to be located at 0x20030034, there the memory reads 0x01000200 which translates to v1.0.2

This address corresponds to the FusInfoTable.FusInfo field.

[HRadt.1]

The MB_DeviceInfoTable_t definition (mbox_def.h) does not match the shared table usage in AN5185.

Other tables seem to be out of sync with reality, too.

[Scott Löhr]

​Hey @HRadt.1​ ​, did you notice this comment in the SHCI_CmdStatus_t SHCI_GetWirelessFwInfo( WirelessFwInfo_t* pWirelessInfo ) function code:

 /**

  * Retrieve the FusInfoTable

  * This table is stored in RAM at startup during the TL (transport layer) initialization

  */

So that implies that you need to load your f/w (using the existing FUS) in order to initialize the TL in order to read the FUS version ... Catch-22! It would seem that your predicament precludes using Alpha h/w - weren't there issues with that alpha h/w running 0.5.3 anyway (i.e. why would you want to use it in production)?

[HRadt.1]

To be clear:

I just wan't to determine the currently installed version in the production process to update to the most up-to-date version.

Currently all chips are supplied with the v0.5.3 FUS installed, but I guess there is no guarantee that this will always be the case. So I want to write a robust implementation that handles also STM32WB chips with a higher version preinstalled.

I figured it out by the way: SHCI_GetWirelessFwInfo uses MB_DeviceInfoTable_t which is missing several fields, that way the offsets of following fields are all wrong.

The implementation is not difficult, but it is quite annoying that the supplied implementation is just plain wrong.

For reference the correct table:

typedef PACKED_STRUCT {
uint32_t TableState;
uint8_t Reserved;
uint8_t LastFusState;
uint8_t LastWirelessState;
uint8_t WirelessStackType;
MB_SafeBootInfoTable_t SafeBootInfoTable;
FusInfoTable_t FusInfoTable;
MB_WirelessFwInfoTable_t WirelessFwInfoTable;
}DeviceInfoTable_t;

The supplied MB_FusInfoTable_t is also wrong, here is the correct one:

typedef PACKED_STRUCT {
uint32_t Version;
uint32_t MemorySize;
}FusInfoTable_t;

Also the SHCI_GetWirelessFwInfo does not check the TableState magic number to check whether it is initialized at all.

[Christophe Arnal]

​Hello,

The CPU2 can run two different binaries which are independent : The FUS and the Wireless Stack.

The mapping of the Device information in SRAM2 is different between the two firmware due to some internal constraints.

SHCI_GetWirelessFwInfo () returns the correct information when CPU2 runs the Wireless firwmware.

When CPU2 runs the FUS, you shall refer to the mapping described in AN5185. There is no command available to read the Device Information when CPU2 runs the FUS.

The ready event reported by the CPU2 when it has booted provides the information on which firmware is running on CPU2.

You may check the BLE_RfWithFlash project which shows how to get the information from the ready event in

APPE_SysUserEvtRx()

Regards.