From 26b1d31eda292d9cd5cfc68f14ce8055256fade8 Mon Sep 17 00:00:00 2001 From: Damien George Date: Wed, 25 May 2022 11:00:42 +1000 Subject: [PATCH] Revert "stm32/rfcore: Intercept addr-resolution HCI cmd to work arou..." 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 --- ports/stm32/rfcore.c | 18 ------------------ 1 file changed, 18 deletions(-) diff --git a/ports/stm32/rfcore.c b/ports/stm32/rfcore.c index 67b63679a7..302f55d7e2 100644 --- a/ports/stm32/rfcore.c +++ b/ports/stm32/rfcore.c @@ -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) {