Closed HaukeRa closed 3 years ago
Hi @HaukeRa ,
Thank you for this report. You request has been forwarded to our development teams. We will get back to you as soon as they provide us with their feedback.
With regards,
I'll chime in that the FUS and wireless stacks appear to have different structures for SHCI_GetWirelessFWInfo(...). E.g. the function works against the BLE wireless stack as-is, but doesn't work against FUS. (I don't know if other wireless stacks implement the FUS structure, or the one present in the BLE stack as I haven't tested the others.)
If I were to guess I'd think the original intent was for both the FUS and wireless stacks to have the same structure here, and it seems like SHCI_GetWirelessFWInfo(...) should work regardless if the FUS or wireless stack is running on the M0+ processor.
And one other thing I discovered on topic (from https://community.st.com/s/question/0D53W00000DIEgjSAH/how-to-reliably-determine-installed-fus-version-from-application-code):
The mapping of the Device information in SRAM2 is different between the two firmware due to some internal constraints.
SHCI_GetWirelessFWInfo(...) could work in either case by inspecting the SBRV value in FLASH->SRRVR. This would let it know if the second CPU is setup to run FUS or a wireless firmware.
It looks like this code now compensates for FUS vs regular firmware as of v1.9.0:
@@ -561,49 +599,93 @@ SHCI_CmdStatus_t SHCI_C2_Config(SHCI_C2_CONFIG_Cmd_Param_t *pCmdPacket)
SHCI_CmdStatus_t SHCI_GetWirelessFwInfo( WirelessFwInfo_t* pWirelessInfo )
{
uint32_t ipccdba = 0;
MB_RefTable_t * p_RefTable = NULL;
- uint32_t version = 0;
- uint32_t memorySize = 0;
- uint32_t infoStack = 0;
+ uint32_t wireless_firmware_version = 0;
+ uint32_t wireless_firmware_memorySize = 0;
+ uint32_t wireless_firmware_infoStack = 0;
+ MB_FUS_DeviceInfoTable_t * p_fus_device_info_table = NULL;
+ uint32_t fus_version = 0;
+ uint32_t fus_memorySize = 0;
ipccdba = READ_BIT( FLASH->IPCCBR, FLASH_IPCCBR_IPCCDBA );
- p_RefTable = (MB_RefTable_t*)((ipccdba<<2) + SRAM2A_BASE);
+
+ /**
+ * The Device Info Table mapping depends on which firmware is running on CPU2.
+ * If the FUS is running on CPU2, FUS_DEVICE_INFO_TABLE_VALIDITY_KEYWORD shall be written in the table.
+ * Otherwise, it means the Wireless Firmware is running on the CPU2
+ */
+ p_fus_device_info_table = (MB_FUS_DeviceInfoTable_t*)(*(uint32_t*)((ipccdba<<2) + SRAM2A_BASE));
+
+ if(p_fus_device_info_table->DeviceInfoTableState == FUS_DEVICE_INFO_TABLE_VALIDITY_KEYWORD)
...
Hi,
The SHCI_GetWirelessFwInfo()
is actually not able to decode the Device Info table for both the FUS and the wireless firmware.
The CPU2 can run two different binaries which are independent : The FUS and the Wireless Stack and the Device Info Table mapping depends on which firmware is running on CPU2.
As, the SHCI_GetWirelessFwInfo()
has been updated within the cube Firmware release v1.9.0, please allow me to close this thread.
With regards,
The DeviceInfo table defined in mbox_def.h does not match the documentation (AN5185).
https://github.com/STMicroelectronics/STM32CubeWB/blob/4a8759ffd65c098010fc60c9b1a2e3d59a1b4c0b/Middlewares/ST/STM32_WPAN/interface/patterns/ble_thread/tl/mbox_def.h#L75-L80
Also the referenced FusInfoTable does not match the documentation (
MB_FusInfoTable_t
), it has an excessive field. Correct:Due to the missing/additional fields, the offsets do not match the documentation anymore, so wrong values are read when accessing the struct members.
Also the method
SHCI_GetWirelessFwInfo
which uses the DeviceInfoTable should check theTableState
member to verify that the table is initialized and return an error when not.