CPU1 crash in certain SDK functions due to CPU2 crash

[tim-nordell-nimbelink]

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(...).

[RJMSTM]

ST Internal Reference: 189571