Bluetooth Controller on ESP32-C6 does not seem to call notify_host_send_available (IDFGH-13797)

[mringwal]

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.3.1-395-g707d097b01

Espressif SoC revision.

ESP32-C6

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.

ESP32C6-N8

Power Supply used.

USB

What is the expected behavior?

Our BTstack (https://github.com/bluekitchen/btstack/) uses the VHCI API on all ESP32 versions that support Bluetooth. On ESP32-C6 with esp-idf v5.3,

What is the actual behavior?

I expect the .notify_host_send_available to be called by the Controller from a thread. I also expect that this happens on a regular thread and not from an ISR.

Steps to reproduce.

• Follow instructions here:
  https://github.com/bluekitchen/btstack/blob/master/port/esp32/README.md
• go to an example, e.g. example/gatt_counter
• $ idf.py set-target esp32-c6
• $ idf.py menuconfig
  • Component -> Bluetooth: enable Bluetooth, but disable Host
  • Component -> BTstack: disable I2S Audio driver
• in src/main, enable logging by uncommenting
  hci_dump_init(hci_dump_embedded_stdout_get_instance());
• in esp-idf/component/btstack/btstack_port_esp32.c, in host_send_pkt_available_cb(), add
  `log_info("host_send_pkt_available_cb!");
• $ idf.py build flash monitor

You'll get a startup log that ends with:

[00:00:00.181] LOG -- btstack_run_loop_freertos.c.236: run loop init, task 0x4081c738, queue item size 8
[00:00:00.181] LOG -- main.c.285: transport_register_packet_handler
[00:00:00.181] LOG -- btstack_tlv.c.48: TLV Instance 0x42075df4
[00:00:00.181] LOG -- le_device_db_tlv.c.159: num valid le device entries 0
[00:00:00.181] LOG -- att_db.c.250: att_set_db 0x42075380
[00:00:00.181] LOG -- hci.c.1681: Num LE Peripheral roles: 0 of 1
BTstack counter 0001
[00:00:00.181] LOG -- hci.c.5531: hci_power_control: 1, current mode 0
[00:00:00.181] LOG -- main.c.205: transport_init
[00:00:00.181] LOG -- main.c.216: transport_open
I (181) BLE_INIT: Using main XTAL as clock source
I (191) BLE_INIT: ble controller commit:[5bc682c]
I (191) BLE_INIT: Bluetooth MAC: 40:4c:ca:56:1a:92
I (191) phy_init: phy_version 310,dde1ba9,Jun 4 2024,16:38:11
I (241) phy: libbtbb version: 04952fd, Jun 4 2024, 16:38:26
[00:00:00.241] LOG -- hci.c.8136: BTSTACK_EVENT_STATE 1
[00:00:00.241] CMD => 03 0C 00
[00:00:00.241] EVT <= 0E 04 01 03 0C 00

The stack stops, as the . notify_host_send_available callback is not called and BTstack is waiting for this.

Debug Logs.

See 'steps to reproduce'

More Information.

I had a look at the NimBLE port for comparison, but got confused as there are two port files.

• esp-idf/components/bt/host/nimble/esp-hci/src/esp_nimble_hci.c
• esp-idf/components/bt/host/nimble/nimble/porting/nimble/src/nimble_port.c

esp_vhci_host_register_callback is only called in esp_nimble_hci.c.

Anyway. Is there a plan to deprecate the .notify_host_send_available? If yes, please let us know how we can find out when the stack can send the next packet.