STMicroelectronics / STM32CubeWB

Full Firmware Package for the STM32WB series: HAL+LL drivers, CMSIS, BSP, MW, plus a set of Projects (examples and demos) running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits).
https://www.st.com/en/embedded-software/stm32cubewb.html
Other
227 stars 138 forks source link

DeviceInfoTable incomplete/not matching documentation #8

Closed HaukeRa closed 3 years ago

HaukeRa commented 4 years ago

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

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;

Also the referenced FusInfoTable does not match the documentation (MB_FusInfoTable_t), it has an excessive field. Correct:

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

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 the TableState member to verify that the table is initialized and return an error when not.

ASELSTM commented 4 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,

tim-nordell-nimbelink commented 4 years ago

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.

tim-nordell-nimbelink commented 4 years ago

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.

tim-nordell-nimbelink commented 3 years ago

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)
...
ASELSTM commented 3 years ago

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,