-
Notifications
You must be signed in to change notification settings - Fork 71
Description
Checklist
- Checked the issue tracker for similar issues to ensure this is not a duplicate
- Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
- Tested with the latest version to ensure the issue hasn't been fixed
How often does this bug occurs?
always
Expected behavior
The ESP32‑C6 should maintain a stable BLE connection as a central, just like:
ESP32‑S3 (NimBLE)
ESP32 (NimBLE)
Android phones
Windows BLE stack
Linux BlueZ
ESPHome Bluetooth Proxy (BlueZ maintains the connection)
These platforms maintain the connection indefinitely.
Actual behavior (suspected bug)
When using the ESP32‑C6 as a BLE central with the ESP‑IDF 5.x/6.x NimBLE host, the device consistently disconnects from certain timing‑sensitive BLE peripherals after approximately 44.7 seconds. The disconnect reason is always:
Code
reason = 546 (ESP_BT_STATUS_CONN_TIMEOUT / supervision timeout)
The same code, same peripheral, and same GATT workflow work perfectly on the ESP32‑S3 (NimBLE), Android, Windows, Linux/BlueZ, and ESPHome Bluetooth Proxy (because BlueZ handles the connection).
This strongly suggests a Link Layer timing issue in the ESP32‑C6 BLE host/controller implementation.
The ESP32‑C6 disconnects after 44.7 ± 0.1 seconds, every time, even when:
No application tasks are running
Wi‑Fi is disabled
Logging is minimized
BLE callbacks do no work
MSYS buffers are increased
IMU streaming or continuous notifications are enabled
Host task stack size is increased
The disconnect reason is always:
Code
reason = 546 (supervision timeout)
This indicates the C6 BLE host/controller is missing a Link Layer control packet or empty PDU deadline.
Error logs or terminal output
Steps to reproduce the behavior
Use ESP32‑C6 as BLE central
Connect to a peripheral that sends periodic notifications
Subscribe to a characteristic
Do not perform any heavy processing
Wait ~45 seconds
Observe disconnect with reason 546
Project release version
latest
System architecture
other (details in Additional context)
Operating system
Linux
Operating system version
FreeRTOS
Shell
ZSH
Additional context
ESP32‑S3 with identical code does not disconnect.
ESP32‑C6 Bluedroid mode cannot be used because notifications/indications are currently non‑functional. (notifiy bug, also not working correctly)
ESPHome Bluetooth Proxy on ESP32‑C6 works because the C6 never maintains the connection — BlueZ does.
The disconnect timing (~44.7s) matches the peripheral’s LL supervision timeout, suggesting missed LL empty PDUs or delayed LL control responses.