Calling esp_ble_gattc_open() on an address that has never been seen triggers interrupt wdt (IDFGH-1625)

[0neblock]

Problem Description

Calling esp_ble_gattc_open() on a hardware address that has never been seen seems to trigger an Interrupt WDT within the BT Library.

Calling esp_ble_gattc_open() on a device that has been scanned, the connection completes successfully and I am able to transfer GATT information and correctly close the connection, but if i try with a module address that has not been seen during scanning, I get the below interrupt wdt timeout.

I have confirmed that BLEScanning has stopped before the esp_ble_gattc_open function is called.

I am calling esp_ble_gattc_open like the below, and i am getting ESP_OK as response.

esp_ble_gattc_open(gattc_profile_list[0].gattc_if, <hardware_addr>, BLE_ADDR_TYPE_RANDOM, true);

I know I am using the function correctly because all i have to do if change the hardware_addr to one that is known and it connects fine.

Environment

Key	Value
Development Kit	Custom Board
Module or chip used	ESP32-WROVER-32
IDF version	91f29bef172a082cbd8f0208ed1757ede0e1d635 - tracking release/v3.3
Build System	Make
Compiler version	crosstool-ng-1.22.0-80-g6c4433a
Operating System	macOS
Power Supply	external 3.3V

Debug Log

| (65436) BT_GATT: GATT_Connect gatt_if=1
I (65456) BT_GATT: GATT_GetConnIdIfConnected status=0

Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)
Core 0 register dump:
PC      : 0x40014f14  PS      : 0x00060c34  A0      : 0x80085dd4  A1      : 0x3ffbe730  
A2      : 0x3ffb3430  A3      : 0x3ffb338c  A4      : 0x000004e2  A5      : 0x00000000  
A6      : 0x0001fff5  A7      : 0x04000000  A8      : 0xfffffffd  A9      : 0x07ffffff  
A10     : 0x00000000  A11     : 0x00000000  A12     : 0x0001ffe0  A13     : 0x0001ffe3  
A14     : 0x04000000  A15     : 0x00000001  SAR     : 0x00000013  EXCCAUSE: 0x00000005  
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000  
Core 0 was running in ISR context:
EPC1    : 0x40093f87  EPC2    : 0x00000000  EPC3    : 0x00000000  EPC4    : 0x40014f14
0x40093f87: vPortCPUReleaseMutexIntsDisabledExtram at /Users/aidan/esp/sensor-pod/esp-idf/components/freertos/tasks.c:5093

ELF file SHA256: 8e979388c43074c6233d6549f9c132ae4d7a56b8e911e09195cc26f3136c490a

Backtrace: 0x40014f14:0x3ffbe730 0x40085dd1:0x3ffbe750 0x40088abe:0x3ffbe780 0x40088566:0x3ffbe7a0 0x400898fd:0x3ffbe7c0 0x4008a6e7:0x3ffbe7e0 0x40083a7d:0x3ffbe800 0x4019d043:0x3ffc4ce0 0x400d3cf7:0x3ffc4d00 0x40094b6d:0x3ffc4d20
0x40085dd1: r_ea_elt_insert at ??:?

0x40088abe: r_lld_evt_end at ??:?

0x40088566: r_lld_evt_end_isr at ??:?

0x400898fd: r_rwble_isr at ??:?

0x4008a6e7: r_rwbtdm_isr_wrapper at intc.c:?

0x40083a7d: _xt_lowint1 at /Users/aidan/esp/sensor-pod/esp-idf/components/freertos/xtensa_vectors.S:1154

0x4019d043: esp_pm_impl_waiti at /Users/aidan/esp/sensor-pod/esp-idf/components/esp32/pm_esp32.c:487

0x400d3cf7: esp_vApplicationIdleHook at /Users/aidan/esp/sensor-pod/esp-idf/components/esp32/freertos_hooks.c:108

0x40094b6d: prvIdleTask at /Users/aidan/esp/sensor-pod/esp-idf/components/freertos/tasks.c:5093

Core 1 register dump:
PC      : 0x4019d046  PS      : 0x00060934  A0      : 0x800d3cfa  A1      : 0x3ffc52e0  
0x4019d046: esp_pm_impl_waiti at /Users/aidan/esp/sensor-pod/esp-idf/components/esp32/pm_esp32.c:487

A2      : 0x00000000  A3      : 0x3ffc15f8  A4      : 0x8009354f  A5      : 0x3ffc5210  
A6      : 0x00000003  A7      : 0x00060023  A8      : 0x800d396a  A9      : 0x3ffc52b0  
A10     : 0x00000000  A11     : 0x3ffbdc90  A12     : 0x8009354f  A13     : 0x3ffc9ec0  
A14     : 0x00000003  A15     : 0x00060023  SAR     : 0x00000000  EXCCAUSE: 0x00000005  
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000  

ELF file SHA256: 8e979388c43074c6233d6549f9c132ae4d7a56b8e911e09195cc26f3136c490a

Backtrace: 0x4019d046:0x3ffc52e0 0x400d3cf7:0x3ffc5300 0x40094b6d:0x3ffc5320
0x4019d046: esp_pm_impl_waiti at /Users/aidan/esp/sensor-pod/esp-idf/components/esp32/pm_esp32.c:487

0x400d3cf7: esp_vApplicationIdleHook at /Users/aidan/esp/sensor-pod/esp-idf/components/esp32/freertos_hooks.c:108

0x40094b6d: prvIdleTask at /Users/aidan/esp/sensor-pod/esp-idf/components/freertos/tasks.c:5093

sdkconfig

https://gist.github.com/0neblock/a6c403e99f9807444b59376d1f243a16

[gengyuchao]

Hello, I tried to use the example gatt_client and changed the address parameter of esp_ble_gattc_open() to "never been seen hardware address." But it didn't crash. So how do you use this feature? Did you do something else before confirming that the connection was actually connected(the ESP_GATTC_CONNECT_EVT event occured )? Such as read or write ?

[0neblock]

Hi,

I will try to describe more my use case. I am connecting to other BLE devices with NRF chips inside. These NRF chips have the ability to get placed into bootloader mode, which will start advertising a service UUID at the original BT Hardware address + 1, after a certain value is written to a GATT characteristic in the normal application.

The problem was occurring specifically when I was connected to the original device, then putting that device in bootloader mode by writing a value, then I would disconnect, and wait for the ESP_GATTC_DISCONNECT_EVT, and then immediately attempt to connect to the same BT address + 1.

I am currently using a workaround to set the device in bootloader mode, then start scanning again, then only after I see that new BT Address + 1 will I try to connect to it, and this seems to be working fine.

[GYC-Espressif]

Thanks for reporting. Has your issue been resolved? If it gets resolved, would you please help close the issue? Thanks.

[Alvin1Zhang]

@0neblock Thanks for reporting, will close due to short of feedback, feel free to reopen if the issue still happens. Thanks.