djsundog/circuitpython
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Revert "stm32/rfcore: Intercept addr-resolution HCI cmd to work arou..."

Browse Source 
This reverts commit 2668337f36deef7fdd97f35e2efc68a5d2102192.

The issue with potential breaking of the BLE RX path in the radio is fixed
since WS v1.12.0.

Signed-off-by: Damien George <damien@micropython.org>
This commit is contained in:
Damien George 2022-05-25 11:00:42 +10:00
parent edf41d2bf8
commit 26b1d31eda
1 changed files with 0 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
ports/stm32/rfcore.c
View File

@ -611,24 +611,6 @@ void rfcore_ble_hci_cmd(size_t len, const uint8_t *src) {
tl_list_node_t *n;
uint32_t ch;
if (src[0] == HCI_KIND_BT_CMD) {
// The STM32WB has a problem when address resolution is enabled: under certain
// conditions the MCU can get into a state where it draws an additional 10mA
// or so and eventually ends up with a broken BLE RX path in the silicon. A
// simple way to reproduce this is to enable address resolution (which is the
// default for NimBLE) and start the device advertising. If there is enough
// BLE activity in the vicinity then the device will at some point enter the
// bad state and, if left long enough, will have permanent BLE RX damage.
//
// STMicroelectronics are aware of this issue. The only known workaround at
// this stage is to not enable address resolution. We do that here by
// intercepting any command that enables address resolution and convert it
// into a command that disables address resolution.
//
// OGF=0x08 OCF=0x002d HCI_LE_Set_Address_Resolution_Enable
if (len == 5 && memcmp(src + 1, "\x2d\x20\x01\x01", 4) == 0) {
src = (const uint8_t *)"\x01\x2d\x20\x01\x00";
}
n = (tl_list_node_t *)&ipcc_membuf_ble_cmd_buf[0];
ch = IPCC_CH_BLE;
} else if (src[0] == HCI_KIND_BT_ACL) {