STM32WB55 - BLE Full Stack 1.13.0 breaks RefTable after PIN entry

[PHutf.1]

Re-post as bug report of my previous topic at https://community.st.com/s/question/0D53W00001JBypZSAT/stm32wb55-ble-full-stack-1130-breaks-reftable-after-pin-entry

We are experiencing difficulties with the BLE Full Stack 1.13.0 on our STM32WB55.

Switching from 1.12.1 where the following scenario works flawlessly, 1.13.0 manages to corrupt part of the RefTable that is located in SRAM2 after doing the following:

- Try pairing with invalid PIN "0000" (pairing is rejected, connection is terminated)

- Pair again with valid PIN

Now the ref table is corrupt (see the attached screenshots) and leads to an access in the address space of the CPU where no RAM is mapped to. That crashes in TL_BLE_SendCmd(uint8_t*, uint16_t) when setting the packet type:

((TL_CmdPacket_t*)(TL_RefTable.p_ble_table->pcmd_buffer))->cmdserial.type = TL_BLECMD_PKT_TYPE;

We tried to find out when/where exactly this happens by checking the integrity of the reftable:

(*(uint32_t*)0x20030000 != 0x20030028U || *(uint32_t*)0x20030004 != 0x20030048U)

at the beginning and end of every IRQ handler, and several consecutive checks when the ACI_GAP_PAIRING_COMPLETE event is handled, since we were able to track the memory corruption in close relation to when we receive this event from the BLE stack.

We also disabled write buffering with the DISDEFWBUF bit to make sure that we can observe the source of the memory corruption well, and we noticed that the memory corruption suddenly happens between these "checkpoints" that we put in place, with no influence from any of our code.

[APort]

I can confirm this exact behavior on 1.13.1 firmware with SC passkey.

[BStic.2]

Did you file a ticket for this? I am also seeing the same corruption, but with a different sequence of events. Also on v1.12.1 stack.

[PHutf.1]

Yes I did now thank you for the heads-up. I wasn't aware of the separate support channel any more. I will update with results ASAP.

[BStic.2]

Thanks. I filed a ticket and they seemed responsive and escalated the issue. I gave them some of my project, but unfortunately I am not able to give all.

Are you using STOP mode for sleeping?

[PHutf.1]

Yes, implemented according to AN5289 Rev 6 pg 22.

[BStic.2]

Thanks, yes same here. The only way I have found to get around this issue so far is to use standby mode instead of STOP. In my system it works fine until I use STOP mode to sleep. Then I get the problem about 50% of the time I attempt my use case. It might be worth a try to see if the problem goes away for you.

[APort]

1. We also contact our representative about this; pending technical team.
2. We don't go trough STOP mode at all and able to always reproduce it.
3. As a temp work-about, to prevent critical failure with unexpected behavior, we reset the CPU on EVT_BLUE_GAP_PAIRING_CMPLT with failure. Not great, but it prevents the random address jump (as it is CVE critial, we will probably have to fill an advisory for this).

[BStic.2]

Another point of information: I had a CPU2 debug pin enabled in aGpioConfigList (IPCC_GENERAL). I disabled it and the problem seemed to have disappeared. Might be worth a try in your case.

[APort]

Not the case for us. We do not use debug pins or trace at all.

The trigger seems to be failed pairing following by successful one (very consistently).