CPU2 crash report during SHCI_C2_BLE_Init(...)

[tim-nordell-nimbelink]

This is a cross post from the community forum, but I haven't gotten a response there to my bug report yet and since this is crashing within the CPU2 side of things an actual bug report here makes sense. It's incredibly difficult to debug the CPU2 side since the code is delivered as an encrypted blob.

Describe the set-up

• Nucleo-WB55 or our custom board utilizing a STM32WB55
• gcc-arm-none-eabi-10-2020-q4-major

Describe the bug Upon invoking SHCI_C2_BLE_Init(...) CPU2 enters a hard fault within the BLE HCI stacks

How To Reproduce I'm not quite sure what it is from our codebase that causes this yet. I could maybe provide a reduced pre-compiled binary to ST, but I cannot provide the full source code from our proprietary project. It's 100% reproducible with our code running on CPU1, and from what I can tell, the HSEM/IPCC/RCC peripherals are all in the same state as the example projects so I'm currently at a loss as to why this occurs. I've also copied all of the SHCI_C2_BLE_Init(...) parameters from some of the newer examples to no avail and validated with gdb that I had the exact same buffer contents being sent to CPU2 in the shared memory through the mailbox mechanism as the transparent mode example codebase.

Within our codebase, I can run v1.11.x through v1.15.0 of the BLE stack and successfully scan for BLE packets. v1.16.x through v1.19.x report a "security attack" upon SHCI_C2_BLE_Init(...) invocation, and v1.20.x has a hard fault. These variations in BLE stack behavior are all without changing the CPU1 firmware.

Here are the hard fault codes of the various v1.20.x HCI stacks as soon as I invoke SHCI_C2_BLE_Init(...) in our codebase:

v1.20.0 of stm32wb5x_BLE_HCILayer_fw.bin has a hard fault:

0x20030000 <TL_RefTable>:       0x1170fd0f      0x00003284      0x00002a33      0x2003f198

v1.20.0 of stm32wb5x_BLE_HCI_AdvScan_fw.bin has a hard fault:

0x20030000 <TL_RefTable>:       0x1170fd0f      0x00003160      0x00001f6f      0x2003ef50

v1.20.0 of stm32wb5x_BLE_HCILayer_extended_fw.bin has a hard fault:

0x20030000 <TL_RefTable>:       0x1170fd0f      0x00003390      0x00002b3f      0x2003f6f8

Please let me know if the PC, SP, and LR inside CPU2 works is sufficient to get an initial fault analysis, or if I need to prepare a minimal pre-compiled binary for CPU1 exhibiting this. I'm still attempting to narrow down what's different between the examples and our codebase - we had integrated the BLE portions of the v1.11.x STM32WBCube codebase quite a while ago but are trying to migrate to the newer version of the BLE stack so we can address the errata around necessitating calling the relatively new SHCI_C2_SetSystemClock(...) command.