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?

[AM.12]

Hello @BStic.2​ ,

Even I am facing the same issue, I am trying to rectify same for the past week. Did u find the root cause? How did you solved this problem?

Thank You.

[BStic.2]

I have not yet found a workaround, as far as I can tell, it has something to do with setting the advertising data after advertising has started. Which is strange, because it seems you cant setup the advertising data before you start advertising. Adding some delays seems to lower the occurrence, but I am about 99% sure they have a race condition in the stack code somewhere.

PS. This type of error seems to pop up over and over again. Ive seen instances of TL_RefTable getting corrupted as far back as v1.12 of the stack.

[AM.12]

Hi @BStic.2​ ,

Thank you for responding, I am using the v1.16 stack. My application is when the button pressed start advertising and after 100ms stop advertising. After pressing the button more than 35 to 40 between this number of times device hangs on advertising. I am new to STM32, so please let me know if you found a workaround for this issue.

[BStic.2]

Ya, starting and stopping advertising seems to be an issue. I am going to refactor using the lower level HCI commands and see if thats any better. These are the functions. hci_le_set_advertising_data and hci_le_set_advertising_parameters

[Remy ISSALYS]

Hello,

According to your screenshot, you have an hardfault, indeed when the CPU2 enters in the hardfault interrupt handler, it writes the following data (extract of AN5289:(

@SRAM2A_BASE: 0x1170FD0F Keyword that identifies a hardfault issue

@SRAM2A_BASE + 4 Program counter value that generated the hardfault

@SRAM2A_BASE + 8 Link register value when the instruction that generated the hardfault has been executed

@SRAM2A_BASE + 12 Stack pointer value when the instruction that generated the hardfault has been executed

With this information, you can find which instruction generate the hard fault in your application.

Best Regards

[BStic.2]

Yes, the hard fault is generated when we deference the bad pointers in TL_RefTable the next time we attempt to send a command to CPU2. The problem is that CPU2 is corrupting the table. See the table in the above screenshot.

Also, I tried this in v1.16.0 stack and the problem is still there.

[Remy ISSALYS]

Hello,

Previous action generates the hardfault, so CPU2 write hardfault keyword in SRAM2A, then when you attempt to send a new command to CPU2, you see this hardfault keyword.

Which stack and which version are you using? When the hardfault occurred, can you check flash register value (FLASH_C2SR (CPU2) and FLASH_SR (CPU1) register)?

Best Regards

[BStic.2]

I am looking through traces to see what is happening on CPU1 when this occurs, but not much is happening. We are basically enabling and disabling advertising. I see this issue both on v1.15.3 and v1.16.0 of the stack. I have tried both the BLE_*full_fw and BLE*_full_extended_fw versions of the stack. I have even switched over from the legacy version of advertising to the extended. Same issue. I will check the flash registers.

[BStic.2]

Hello, sorry for the delay. This issue takes a while to duplicate. The FLASH_C2SR is 0x80000 and FLASH_SR is 0x80000. What is the significance of the flash registers?

Another note, We are using LE Privacy (random resolvable addresses) and if I disable it and just use my static random address this issue goes away.