-
Notifications
You must be signed in to change notification settings - Fork 8k
Description
Answers checklist.
- I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
- I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
- I have searched the issue tracker for a similar issue and not found a similar issue.
IDF version.
v5.4.3, v6.1-dev-1532-gb6e2de03f0
Espressif SoC revision.
ESP32-S3
Operating System used.
macOS
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
Waveshare ESP32-S3-Touch-LCD-7
Power Supply used.
USB
What is the expected behavior?
I expect the ESP_HIDH_CLOSE_EVENT to be sent when a Bluetooth HID device disconnects. I also expect that the device's memory is freed.
What is the actual behavior?
The following appears in the log, but the close event is never sent:
I (26073) NimBLE: disconnect; reason=520
The close event is not sent because the connected flag is never set to true (in nimble_hidh.c). As a result, the device is never freed and the close event is never sent.
Setting dev->connected = true in esp_ble_hidh_dev_open before sending the OPEN event or in esp_hidh_gattc_event_handler when handling BLE_GAP_EVENT_CONNECT seems to fix the issue.
Steps to reproduce.
- Initialise BLE and start scanning.
- Turn on Bluetooth HID device and wait until it is paired and working.
- Disconnect or turn off Bluetooth HID device.
- Expect ESP_HIDH_CLOSE_EVENT to be logged and device to be freed.
// Start scanning and find Bluetooth HID device
// ...
// Once HID device has been found, try to open it
esp_hidh_dev_t* dev = esp_hidh_dev_open(
keyboard.ble_addr.val,
ESP_HID_TRANSPORT_BLE,
keyboard.ble_addr.type);
// Naive polling to see device is properly freed
while (esp_hidh_dev_exists(dev)) {
vTaskDelay(pdMS_TO_TICKS(1000));
}
// This while loop currently never exitsDebug Logs.
Diagnostic report archive.
No response
More Information.
I believe this could be a simple issue of "connected" never being set to true. Of course, it also raises the question of what "connected" is used for and why one would not want to free the device on BLE_GAP_EVENT_DISCONNECT if connected is in fact false.