hci connection timed out in esp_hosted_ng

[MrSumi]

Hi guys, I got hci connection timed out when using esp-hosted-ng.

Environment:

ESP driver: ESP32 SDIO(WiFi) + UART(BT) Linux Host: kernel 4.19, bluez 5.65 Commit: 651abba818acfbfe4fa3f8d62a412539603c66a6

The hci device work fine after btattach. But after a few connecting and disconnecting on BT/BLE, it has no respond, and come out with: # hciconfig -a hci0: Type: Primary Bus: UART BD Address: CC:DB:A7:48:B1:62 ACL MTU: 1021:9 SCO MTU: 255:4 UP RUNNING PSCAN ISCAN RX bytes:2589213 acl:23462 sco:0 events:32909 errors:0 TX bytes:6052476 acl:25684 sco:0 commands:7162 errors:0 Features: 0xbf 0xee 0xcd 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT Can't read local name on hci0: Connection timed out (110)

Here's logs in ESP32 serial port: ESP32 Serial Debug 2023-11-16 111810.txt

Here's logs in Linux dmesg: Linux dmesg MobaXterm_20231116_111738.txt

I had tried btattach again, but it didn't work. Until i reset the ESP32, and btattach again, it work fine.

[MrSumi]

I had also try patching hci code to Linux 4.19.298, but it didn't work.

[mantriyogesh]

Hello @MrSumi ,

Can you please share your setup image?

[mantriyogesh]

1. I see the bluetooth connection is 'UP RUNNING'. This means your base UART connection exchange had worked, at least for some time

2. I also observe there are timeout errors in the Linux log. The Bluetooth over UART is transparent and packets are directly pushed from Linux Bluetooth stack to UART to ESP's Bluetooth controller. In this mode, only Bluetooth init and deinit instruction is communicated over SDIO. Once init is done, UART is expected to work transparently (Messages/packets would not enter ESP-Hosted kernel module).

3. Another observation, I fail to see ESP bootup event in Linux from ESP. The debug logs are enabled by default: https://github.com/espressif/esp-hosted/blob/63f12ead9c4a77d372b24f3420c85e9018bec80b/esp_hosted_ng/host/Makefile#L15

So why https://github.com/espressif/esp-hosted/blob/63f12ead9c4a77d372b24f3420c85e9018bec80b/esp_hosted_ng/host/main.c#L178-L204 was not printed?

Something like:

[ 1706.329529] EVENT: 3
[ 1706.329556] ESP chipset detected [esp32]
[ 1706.329584] EVENT: 0
[ 1706.329610] ESP peripheral capabilities: 0x1d
[ 1706.544526] ESP Bluetooth init
[ 1706.544923] Capabilities: 0x1d. Features supported are:
[ 1706.544956]   * WLAN on SDIO
[ 1706.544996]   * BT/BLE
[ 1706.545022]     - HCI over UART
[ 1706.545048]     - BT/BLE dual mode
[ 1706.545075] EVENT: 1

was expected in Linux log.

4. What is the ESP chipset used? (I see the expected transport combination is SDIO + UART)

5. Is the Linux host Raspberry Pi or something else?

6. If you do

   sudo killall hciattach

   and then re-run rpi_init.sh (build and reload the driver), does it work?

7. if still doesn't work, what happens if

   sudo hciconfig hci0 reset

8. Can you please gather the

   sudo btmon &

   logs ( preferrably in same terminal window) along with

   sudo bluetoothctl

9. Finally, in reference to (3), Can you please check if SDIO only mode (Bluetooth & Wi-Fi over SDIO) works and prints the bootup event?

It is worth to check https://github.com/espressif/esp-hosted/blob/master/esp_hosted_ng/docs/porting_guide.md once, just to cross check if anything missed to be done while porting.

[mantriyogesh]

Commit: https://github.com/espressif/esp-hosted/commit/651abba818acfbfe4fa3f8d62a412539603c66a6

Possible to test above over master commit? You would need to use same git commit for ESP side flashing.

[MrSumi]

Hello @mantriyogesh ,

Thanks for giving useful advice!

1. I see the bluetooth connection is 'UP RUNNING'.
2. I also observe there are timeout errors in the Linux log.

Yes, it works fine in early bootup time. But it turns timeout after BT or BLE devices trying connect or disconnect.

3. Another observation, I fail to see ESP bootup event in Linux from ESP. 4 .What is the ESP chipset used? (I see the expected transport combination is SDIO + UART)
4. Is the Linux host Raspberry Pi or something else?

Actually we run Linux host in imx8mini platform and ESP32 for driver, and debug log is disable. So, the bootup message may not print.

6. If you do sudo killall hciattach

I do btattach -B /dev/ttymxc0 -S 3000000 -P h4 for attaching hci controller, and i had tried kill it and re-attach, but it didn't work. Until i reset the ESP32, and btattach again, it work fine. Also, i'm quite sure the SDIO driver works fine, because i trans some ADC result over it and it works fine.

7. if still doesn't work, what happens if sudo hciconfig hci0 reset
8. Can you please gather the sudo btmon &

I would try those suggestions for catching logs, thx!

BTW, I had also tried runing hci controller example in idf-5.1.1, but it also came out with this problem.

[mantriyogesh]

btattach -B /dev/ttymxc0 -S 3000000 -P h4

The argument value for '-S' argument should match the UART baud rate running over ESP chipset. Default baud rate may vary depending upon ESP chipsets you use. But it is generally expected (default configured) to be 921600.

ESP logs would be really needed, to confirm this.

• If you are using released firmware binary, check the sdkconfig file from where you had flashed the binaries.
• If you are flashing from source, you will be able to find sdkconfig file where you run idf.py flash monitor.

In sdkconfig file, you would be able search for CONFIG_BTDM_CTRL_HCI_UART_BAUDRATE being used. You must use the same value at host while communicating with HCI over UART.. This value is configurable when you flash from source. You can refer the setup instructions in ESP-Hosted-NG documentation.

[mantriyogesh]

BTW, the name of CONFIG_BTDM_CTRL_HCI_UART_BAUDRATE differs per chipset or depending upon use like, BTDM is dual, Classic-Bt + BLE. If BLE only used, the name may differ. You need to try with default firmwares,

btattach -B /dev/ttymxc0 -S 921600 -P h4

For baud rate used in firmware, try to search, 'HCI_UART_BAUDRATE' in sdkconfig file. If you are flashing from source, you can attach the sdkconfig file here.

[MrSumi]

Got it, but i have manully change baudrate to 3000000 in source. It can successfully attach to host, hciconfig gets the MAC address and the bluez stack works fine. But it just become timeout after running several times while we are testing for connecting and disconnecting bluetooth device. Would it be possible that the higher baudrate cause this problem?

[mantriyogesh]

ESP-IDF might have tested higher baud rates than 921600. More than baud rate there would really mean faster transactions and smaller time windows. Q. How are you connecting the setup? Q. Do you use PCB for UART?

We have not tested more than 921600, but whatever ESP-IDF supports, we can reach that level (as I said earlier, it UART over HCI is transparent and doesn't involve ESP-Hosted as such).

First step could be to test if 921600 is reliable for your connections. If you use jumper wires, might want to use equal length smaller wires. Q. Do you use 2 wired UART or 4 wired UART?

[MrSumi]

In our case, we use 4 wired UART layout in PCB.

According to the IDF config file, the highest hci uart baudrate is 921600. But we can also change it manully in source to reach higher bandwide, like this:

    esp_bt_controller_config_t bt_cfg = BT_CONTROLLER_INIT_CONFIG_DEFAULT();
    ret = esp_bt_controller_init(&bt_cfg);
    if (ret != ESP_OK) {
        ESP_LOGE(tag, "Bluetooth Controller initialize failed: %s", esp_err_to_name(ret));
        return;
    }

    ESP_ERROR_CHECK(uart_set_baudrate(CONFIG_BTDM_CTRL_HCI_UART_NO, 3000000));

    ret = esp_bt_controller_enable(ESP_BT_MODE_BTDM);
    if (ret != ESP_OK) {
        ESP_LOGE(tag, "Bluetooth Controller initialize failed: %s", esp_err_to_name(ret));
        return;
    }

[mantriyogesh]

Hello @MrSumi

I tried on other chipset with FG (Doesn't really matter as the communication is all same for base transport UART) With 3,000,000 UART baud rate, I got it fine working. Tested till scan only. But anyway, all communication is transparent to ESP-Hosted and no filtering as such is done, so everything should just work. c6_baudrate_uart_3000000.pdf rpi_commands_output.pdf attached the logs.

For C6, I had used 3000000 value as HCI over UART baud rate using idf.py menuconfig -> and done idf.py flash monitor to flash and log.

ESP32 menuconfig may have option at little different place, but doesn't matter.

[MrSumi]

Hi @mantriyogesh

Thanks for your useful advice! I tried running the hci with UART2 baudrate 921600, here's my sdkconfig:

Unfortunately, it still came out this problem.

Here's the tirminal output with hciconfig -a and dmesg: terminal_output_20231122_181107.txt

Here's my btmon logs: btmon.log

[mantriyogesh]

1. Anyway, I don't relate this issue to ESP-Hosted's kernel module, as UART communication is agnostic of ESP-Hosted.
2. the linux driver (for your platform) for BlueZ over UART is returning cannot allocate memory (12). It could be an issue in the Bluetooth controller or your kernel driver upon some race condition.

To check if this is Bluetooth controller issue, you can recreate this issue with IDF HCI example (one you had used earlier) and can actually open ESP-IDF ticket for faster resolution.

3. Is there any specific steps to reproduce this issue?
4. Any crash/error log you observe on ESP32 when this issue happens?

[mantriyogesh]

The BT team is already checking if this is Bluetooth controller issue, by the time. But this may take some time.

But anyway, if you are able to reproduce this issue directly over ESP-IDF, issue would be addressed faster.

[mantriyogesh]

@MrSumi Any further update?

[mantriyogesh]

Issue was dependent upon IDF issue, https://github.com/espressif/esp-idf/issues/12650 As IDF issue is closed, closing this issue.