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).
The default placement of TL_Reftable causes CPU2 to overwrite the p_device_info_table, p_ble_table, p_thread_table, and p_sys_table variables within TL_Reftable when CPU2 crashes. The SDK code does not check for the crash condition from CPU2 and happily dereferences the values that CPU2 placed into this table causing CPU1 to crash. For instance, if CPU2 has crashed, invoking SHCI_GetWirelessFwInfo(...) from CPU1 will cause CPU1 to crash from this dereference.
I'd suggest that each usage of the pointers within TL_Reftable should check if one of the magic values that indicates a crash from CPU2 has been written to the top of SRAM2 before dereferencing these (potentially invalid) pointers.
Reproduction involves causing CPU2 to crash, and then invoking one of the functions that dereferences the pointers from TL_Reftable such as (but not limited to) SHCI_GetWirelessFwInfo(...).
The default placement of TL_Reftable causes CPU2 to overwrite the
p_device_info_table
,p_ble_table
,p_thread_table
, andp_sys_table
variables within TL_Reftable when CPU2 crashes. The SDK code does not check for the crash condition from CPU2 and happily dereferences the values that CPU2 placed into this table causing CPU1 to crash. For instance, if CPU2 has crashed, invokingSHCI_GetWirelessFwInfo(...)
from CPU1 will cause CPU1 to crash from this dereference.I'd suggest that each usage of the pointers within
TL_Reftable
should check if one of the magic values that indicates a crash from CPU2 has been written to the top of SRAM2 before dereferencing these (potentially invalid) pointers.Reproduction involves causing CPU2 to crash, and then invoking one of the functions that dereferences the pointers from TL_Reftable such as (but not limited to)
SHCI_GetWirelessFwInfo(...)
.