Skip to content

ESP32‑C6 BLE Central Disconnects After ~44.7 Seconds With Timing‑Sensitive Peripheral #116

@itrkrukk

Description

@itrkrukk

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions