Skip to content

esp_hidh, NimBLE: ESP_HIDH_CLOSE_EVENT event never sent when device disconnects (also memory leak) (IDFGH-17013) #18059

@topschrott

Description

@topschrott

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.

  1. Initialise BLE and start scanning.
  2. Turn on Bluetooth HID device and wait until it is paired and working.
  3. Disconnect or turn off Bluetooth HID device.
  4. 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 exits

Debug 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.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions