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.
