STM32WB CPU2 hard fault in HCI stack variants in v1.20.0

[Tim.N]

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

[Tim.N]

Cross posted to https://github.com/STMicroelectronics/STM32CubeWB/issues/99.

[Remy ISSALYS]

Hello,

I look the information that you have shared on GitHub, according to your explanation, in your project you use the stm32wb5x_BLE_HCILayer_fw.bin and you set the SHCI_C2_Ble_Init_Cmd_Param_t's Options field bit 0 to 1 which means LL + Host.

Indeed, from version v1.16.0, the check of the validity of phci_acl_data_buffer has been modified. In your case, it seems that the phci_acl_data_buffer is not in the unsecure SRAM (all the buffer or only a part of it), that's why you saw the security attack keyword at address SRAM2A_BASE. 

To check this point, can you share the buffer location and the buffer size? Can you share also the option byte values (NBRSD, SNBRSA, BRSD, SBRSA)? 

Regarding the others point mentioned in your post I will check. 

For you other post on GitHub, when the CPU2 enters the hard fault interrupt handler, some information is written in SRAM2A before running an infinite loop. Then, the CPU2 is no more functional. 

Best Regards

[Tim.N · Accepted solution]

Hi Remy -

Mainly the security fault occurred since I'm trying to use the helper functions in the SDK for hci_init(...), hci_reset(...), and family. The hci_init(...) call ends up placing an uninitialized stack value into phci_acl_data_buffer.  I worked around this by manually setting the pointer, although, I'm confident it's *never* used in our application so it's unfortunate this can't be left as a NULL and leave the option bit field to LL + Host like previously:

PLACE_IN_SECTION("MB_MEM2") ALIGN(4) static uint8_t HciAclDataBuffer[sizeof(TL_PacketHeader_t) + 5 + 251];
...

   hci_init(...);

   // Manually configure phci_acl_data_buffer which hci_init(...) doesn't
   // initialize properly in the current SDK.   v1.16.0 and up requires this
   // to be set for any of the HCI stack variants.
   MB_RefTable_t *ref_table = (MB_RefTable_t *)(SRAM2A_BASE);
   ref_table->p_ble_table->phci_acl_data_buffer = HciAclDataBuffer;

None of the examples utilize hci_init(...) and family with the HCI stack variants which is probably why ST never had this happen to them.  The SDK cannot be used as-is with hci_init(...) with v1.16.x+ for the HCI variants of the stack, but it is usable with v1.15.x and earlier.  Since we used it that way our code stopped being interoperable as-is with the SDK when we tried to use v1.16.x and above.

Regardless, there are at least a two bugs which are noted in the github ticket:

1. v1.20.x emits a hard fault instead of a security fault
2. hci_init(...) places garbage data into phci_acl_data_buffer via invoking TlInit(...); it should *at least* clear out the pointers to NULL if it's not going to set them to anything meaningful.

Additionally, it'd be nice if using hci_init(...) and friends was possible again with the HCI variants of the firmware without working around bugs like phci_acl_data_buffer not being set meaningfully with the SDK.  I can't imagine that the stm32wb5x_BLE_HCI_AdvScan_fw.bin even can use ACL buffers since it can't connect to other BLE devices, yet in v1.16.x it now requires the ACL buffer to be allocated.  Our use case is purely for scanning for advertising packets and we never connect.

- Tim

[Remy ISSALYS]

Hello,

Indeed, from v1.16.0, you should initialize ACL data buffer for all the HCI variants of the stack. It's done in BLE_TransparentMode application which can work in HCI mode. In your cases, it worked in the previous version because you configure the option bit field to LL + Host while you used a HCI stack variant. 

Regarding stm32wb5x_BLE_HCI_AdvScan_fw.bin firmware, indeed the ACL buffers are not used as connection is not supported in this variant. 

Regarding the point 1, issue has been identified and will be fixed for the next release. 

Regarding the point 3, I will check internally, someone from ST will contact you.

Best Regards

[Tim.N]

---

---

---

@Remy ISSALYS wrote:

Regarding stm32wb5x_BLE_HCI_AdvScan_fw.bin firmware, indeed the ACL buffers are not used as connection is not supported in this variant. 

---

Is it a bug then that this variant requires allocation for ACL buffers but cannot use them?

[Remy ISSALYS]

Hello,

No, it's not a bug, the check is conditional only on the fact that HCI firmware is used and not specific for each variant.

Best Regards