Hello!
I'm trying to update from v1.11.0 to the latest stack in our firmware for stm32wb5x_BLE_HCILayer_fw.bin to address the errata around the utilizing the PLL, but CPU2 is hard faulting as soon as we invoke SHCI_C2_BLE_Init(...).
I can run and load v1.11.0 through v1.15.0 of the stack without touching our code.
Versions v1.16.0 through v1.19.0 report a "security attack" by setting the top of TL_RefTable to 0x3DE96F61.
v1.20.0 of stm32wb5x_BLE_HCILayer_fw.bin has a hard fault:
0x20030000 <TL_RefTable>: 0x1170fd0f 0x00003284 0x00002a33
v1.20.0 of stm32wb5x_BLE_HCI_AdvScan_fw.bin has a hard fault:
0x20030000 <TL_RefTable>: 0x1170fd0f 0x00003160 0x00001f6f
v1.20.0 of stm32wb5x_BLE_HCILayer_extended_fw.bin has a hard fault:
0x20030000 <TL_RefTable>: 0x1170fd0f 0x00003390 0x00002b3f
I've tried copying the newer parameters (e.g. overwriting my app_conf.h) from the newer examples for SHCI_C2_BLE_Init(...) into our codebase, but it doesn't change this behavior.
I can take our codebase and run it on the P-Nucleo-WB55 devkit and get the same hard faults on CPU2. (Running the BLE_TransparentMode example code as-is does work on the P-Nucleo-WB55 devkit.)
Any ideas what may have changed between v1.11.0 and v1.20.0 that we'd have to update in our codebase beyond the PLL calls? Any new peripheral usage by CPU2 that our code may also be using where CPU2 faults due to our usage?(For instance, I've discovered undocumented conflicts between the CRC peripheral and the FUS code in the past.)
Thanks,
Tim
