STM32WB55 CPU2 Corrupts TL_RefTable while configuring BLE advertising (stack v1.15.0)

[BStic.2]

Ive seen this issue in various different forms over the last 2 years and it seems like CPU2 is corrupting the TL_RefTable structure while configuring advertising. We are using v1.15.0 of the stack on a STM32WB55. This happens every few hours in the following sequence.

aci_gap_set_non_discoverable();
// Wait 40 seconds
aci_hal_set_tx_power_level(1, powLevel);
aci_gap_set_discoverable(ADV_IND, RateMin, RateMax, addrType, NO_WHITE_LIST_USE, 0, NULL, 0, NULL, 0, 0);
aci_gap_update_adv_data(Manufacturing specific type)
aci_gap_update_adv_data(Name)
aci_gap_delete_ad_type(AD_TYPE_TX_POWER_LEVEL)
// Wait 20 seconds

Then the sequence repeats over and over until we get a connection. If I just let it run (over night for example) TL_RefTable gets corrupted and triggers an MPU fault on the next advertising sequence.

 

Why is this happening? What can I do to stop it?

[BStic.2]

I do not try to connect to the device when it is in this state, but I have seen other connections from BLE devices around my house that I did not intend. In this case they are eventually disconnected due to our security timeout of 20 seconds, then we resume the sequence. I have not seen a connection in close proximity to this issue. We have 1 bonded device in the resolving list when this happens. We do not use the whitelist for either the fast or slow advertising state (only reconnect - which is only triggered if the connection is lost due to a connection timeout). The problem with the binary is that we have a custom board with custom GPIO and external memory that we rely on. It would not run as-is on a demo board.

I will talk with my manager and see if he would allow me to trim things down and send an srecord.

[Remy ISSALYS]

Hello,

If understand well, when you run the test that leads to the issue (HF), you are running in loop an (slow) adv during 20s every 40s, with Privacy enabled. There are no device around which are in the resolving list and that could attempt a connection. However some other devices around you, are connecting (despite of privacy is enabled). You tell that they are disconnected (after a 20s timeout). Is this disconnection of the spurious peer, or eventually its disconnection due to supervision timeout (before your 20s timeout) could lead to the sequence that reconfigure white list (from resolving list) and then run fast adv during 30s with white list enabled ? (We try to figure out if your test setup leads to call many times BLECON_configAdvReconnect() et more particularly aci_gap_configure_whitelist()).

If you can tune the code to run it on nucleo board and provide a binary, it would be a good starting point to reproduce the issue on our side and investigate it.

Best Regards