espressif / esp-hosted

Hosted Solution (Linux/MCU) with ESP32 (Wi-Fi + BT + BLE)
Other
675 stars 158 forks source link

esp32c3 spi hosted-fg: Unable to configure Bluetooth using some hci commands #381

Closed wmdscjhdpy closed 4 months ago

wmdscjhdpy commented 4 months ago

I use esp32c3 module on a embedded linux system. I can use bluetoothctl to turn on BLE advertising, but when I use hci protocol to setup device:

hciconfig hci0 up
hciconfig hci0 leadv

It return a non-zero result:LE set advertise enable on hci0 returned status 12.

And, when I want to use C program to setup bluetooth, it doesn't work: hci lib return errno EIO.

I try to watch esp32c3 device log to find more infomation, but this log is too simple and no BT info in my log:

# esp32_log.sh
I (1871963) slave_ctrl: HB timer started for 20 sec

I (1871973) wifi:mode : softAP (54:32:04:80:8d:89)

I (1871973) wifi:Total power save buffer number: 16

I (1871973) wifi:Init max length of beacon: 752/752

I (1871973) wifi:Init max length of beacon: 752/752

I (1871973) slave_ctrl: softap mode set

I (1871983) slave_ctrl: mac [54:32:04:80:8d:89]

I (1871983) slave_ctrl: 54:32:04:80:8d:89

I (1872643) wifi:Total power save buffer number: 16

I (1872643) slave_ctrl: ssid ESPWifi pwd ESPWifi@123 authmode 3 ssid_hidden 0 max_conn 4 channel 1

I (1872643) slave_ctrl: ESP32 SoftAP is avaliable

I (1872653) NETWORK_ADAPTER: Get softap mac address

I (1872653) NETWORK_ADAPTER: AP mac [54:32:04:80:8d:89]

I (1872663) slave_ctrl: softap stop handler stop

I (1872663) NETWORK_ADAPTER: Get softap mac address

I (1872673) NETWORK_ADAPTER: AP mac [54:32:04:80:8d:89]

I (1875663) slave_ctrl: Stop Heatbeat

I (1875663) slave_ctrl: Stopping HB timer

I see the docs and know that "hcitool lescan is deprecated", but I wonder if esp32 can't even support standard hci commands? Linux Kernel version:5.10.160 bluetoothctl version:5.45

Thx.

mantriyogesh commented 4 months ago

Additional information required

Can you please get us following info:

  1. What is transport used for bluetooth (spi or uart?) Bluetooth messages take different route in 'HCI over SPI' or 'HCI over UART'.
  2. Commit used at slave and host?
  3. Host dmesg from bootup
  4. ESP log from bootup
  5. Commands run (say hci* or bluetoothctl shell) and their output
  6. Bluetooth service i.e. bluetoothd debug logs (BlueZ specific userspace debug log) ***
  7. sudo btmon (standard HCI protocol logs) from start ***

    *** -- optional for now better to include if so not want repeat test

Response to the questions asked

but I wonder if esp32 can't even support standard hci commands?

I think you might already be aware (if not already confused) of the difference between HCI commands and HCI protocol/interface.

HCI commands are just tools or user space commands , very dependent on specific stack BlueZ. HCI standard protocol/interface is a standard, which needs to be avoided by any host bluetooth stack, for example, BlueZ.

Relationship details of ESP-Hosted with BlueZ and HCI

The ESP-Hosted is simple relay of Bluetooth messages from bluetooth host stack like BlueZ running at host to Bluetooth controller running at ESP. communication is using standard HCI protocol.

ESP hosted does not understand or process the messages originated from host, it just transparently sends what it received from BlueZ.

What I meant, if BlueZ deprecated any command, you might have to use the utility provided or supported by BlueZ. bluetoothctl is utility provided by BlueZ, which is just used to demonstrate the bluetooth working.

To answer your question, the ESP chipset supports any messages received from bluetooth host stack (BlueZ), if they are HCI standard. User need to align their bluetooth communication which they interact with user space commands provided at BlueZ.

There is no standard HCI commands (you might be referring to generally used commands provided by BlueZ userspace ). The protocol is standard, HCI.

If you have some issues while running commands can you please get above stated logs to understand the issue:

Extra Bluetooth logs for HCI over SPI

slave side logs could be enabled:

https://github.com/espressif/esp-hosted/blob/040cfdb35db4270c443146b19febf6c59266d419/esp_hosted_fg/esp/esp_driver/network_adapter/main/slave_bt.c#L95

https://github.com/espressif/esp-hosted/blob/040cfdb35db4270c443146b19febf6c59266d419/esp_hosted_fg/esp/esp_driver/network_adapter/main/slave_bt.c#L75

Host side logs could be enabled: https://github.com/espressif/esp-hosted/blob/040cfdb35db4270c443146b19febf6c59266d419/esp_hosted_fg/host/linux/host_driver/esp32/esp_bt.c#L93

https://github.com/espressif/esp-hosted/blob/040cfdb35db4270c443146b19febf6c59266d419/esp_hosted_fg/host/linux/host_driver/esp32/main.c#L460

The HCI over UART takes different route, let us know if you use HCI over UART.

wmdscjhdpy commented 4 months ago

Thank you for your response.

The additions to the requested information are as follows:

  1. bluetooth using SPI transfer
  2. I'm sorry that I can't get the commit information, but the source code is in the buildroot of the corresponding board and the git file is missing.

Despite the limited information available, I have captured the runtime logs of btmom and blutoothd, as well as the output of the execution commands in the terminal, which is given in the attached file. issue_log.zip

Before that, I briefly analyzed the logs I captured, and I noticed a phenomenon: when I use hciconfig hci0 leadv, the hci process captured by btmom is shown as "Command Disallowed".

@ RAW Open: hciconfig (privileged) version 2.22      {0x0005} [hci0] 314.457417
< HCI Command: LE Set Advertisin.. (0x08|0x0006) plen 15  #51 [hci0] 314.457809
        Min advertising interval: 1280.000 msec (0x0800)
        Max advertising interval: 1280.000 msec (0x0800)
        Type: Connectable undirected - ADV_IND (0x00)
        Own address type: Public (0x00)
        Direct address type: Public (0x00)
        Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
        Channel map: 37, 38, 39 (0x07)
        Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4               #52 [hci0] 314.461229
      LE Set Advertising Parameters (0x08|0x0006) ncmd 5
        Status: Command Disallowed (0x0c)
< HCI Command: LE Set Advertise E.. (0x08|0x000a) plen 1  #53 [hci0] 314.463790
        Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4               #54 [hci0] 314.471042
      LE Set Advertise Enable (0x08|0x000a) ncmd 5
        Status: Command Disallowed (0x0c)
@ RAW Close: hciconfig                               {0x0005} [hci0] 314.471961

But if I use the bluetoothctl utility to turn on broadcasting via advertise on, the broadcast commands recorded by btmom belong to extend advertising instead of regular advertising:

@ MGMT Command: Add Advertising (0x003e) plen 11     {0x0003} [hci0] 337.082058
        Instance: 1
        Flags: 0x00000003
          Switch into Connectable mode
          Advertise as Discoverable
        Duration: 0
        Timeout: 0
        Advertising data length: 0
        Scan response length: 0
@ MGMT Event: Advertising Added (0x0023) plen 1      {0x0002} [hci0] 337.082947
        Instance: 1
@ MGMT Event: Advertising Added (0x0023) plen 1      {0x0001} [hci0] 337.082947
        Instance: 1
< HCI Command: LE Set Extended A.. (0x08|0x0036) plen 25  #57 [hci0] 337.083080
        01 13 00 00 08 00 00 08 00 07 00 00 00 00 00 00  ................
        00 00 00 7f 01 00 01 00 00                       .........
> HCI Event: Command Complete (0x0e) plen 5               #58 [hci0] 337.091257
      LE Set Extended Advertising Parameters (0x08|0x0036) ncmd 5
        Status: Success (0x00)
        03                                               .
< HCI Command: LE Set Extended S.. (0x08|0x0038) plen 35  #59 [hci0] 337.091316
        01 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00                                         ...
> HCI Event: Command Complete (0x0e) plen 4               #60 [hci0] 337.101130
      LE Set Extended Scan Response Data (0x08|0x0038) ncmd 5
        Status: Success (0x00)
< HCI Command: LE Set Extended Ad.. (0x08|0x0039) plen 6  #61 [hci0] 337.101179
        01 01 01 00 00 00                                ......
> HCI Event: Command Complete (0x0e) plen 4               #62 [hci0] 337.111327
      LE Set Extended Advertising Enable (0x08|0x0039) ncmd 5
        Status: Success (0x00)
@ MGMT Event: Command Complete (0x0001) plen 4       {0x0003} [hci0] 337.111376
      Add Advertising (0x003e) plen 1
        Status: Success (0x00)
        Instance: 1
< HCI Command: LE Set Extended A.. (0x08|0x0037) plen 35  #63 [hci0] 337.111390
        01 03 01 03 02 01 06 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00                                         ...
> HCI Event: Command Complete (0x0e) plen 4               #64 [hci0] 337.121763
      LE Set Extended Advertising Data (0x08|0x0037) ncmd 5
        Status: Success (0x00)

This is probably the question I was hoping to know: can the esp32c3 support regular LE advertising? Maybe this question can be simply reproduced on a linux host such as a raspberry pi, but I'm not in a position to test it. If the hci instruction for LE advertising is something that can apparently be supported for the esp32c3, then I should probably check the software and drivers for my host's user space.

Looking forward to your reply and thanks again!

mantriyogesh commented 4 months ago

The hciconfig is deprecated since long and no longer maintained:

https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=b1eb2c4cd057624312e0412f6c4be000f7fc3617

Deprecated tools by BlueZ: https://archlinux.org/packages/extra/x86_64/bluez-deprecated-tools/#:~:text=http://www.bluez.org,list%20for%20bluez-deprecated-tools

Can you please get this scenario tested using bluetoothctl?

mantriyogesh commented 4 months ago

In addition to above, I see https://www.spinics.net/lists/linux-bluetooth/msg88895.html

mantriyogesh commented 4 months ago

Please check above link that says,

If, since the last power-on or reset, the Host has ever issued a legacy advertising command and then issues an extended advertising command, or has ever issued an extended advertising command and then issues a legacy advertising command, the Controller shall return the error code Command Disallowed (0x0C).

Extended parameters enabled already here: Screenshot 2024-05-16 at 10 20 39 AM

So advertising parameters not gettting set & hence non-extended results in failure. Screenshot 2024-05-16 at 10 19 12 AM

wmdscjhdpy commented 4 months ago

Please check above link that says,

If, since the last power-on or reset, the Host has ever issued a legacy advertising command and then issues an extended advertising command, or has ever issued an extended advertising command and then issues a legacy advertising command, the Controller shall return the error code Command Disallowed (0x0C).

Extended parameters enabled already here: Screenshot 2024-05-16 at 10 20 39 AM

So advertising parameters not gettting set & hence non-extended results in failure. Screenshot 2024-05-16 at 10 19 12 AM

When testing, I always try to use the hci command for LE advertisements first (via the deprecated utility hciconfig), and then the LE extended advertisements command (via the utility bluetoothctl), so in that order, it shouldn't be disallowing LE advertisements, but disallowing LE extended advertisements. It should not be disallowing LE ads, but disallowing LE Extended Ads. However, you've made it clear to me that it's possible that the LE Extended Ads command was used when booting the linux host, resulting in a subsequent disabling of the LE Ads command. I will continue to check my runtime environment and have confirmed if this is the case. If you know how to specify bluetoothctl to use LE advertisements instead of LE extended advertisements (when I use the advertise on command now, the command sent can only be LE extended advertisements), please let me know that as well, and thank you for your prompt reply!

mantriyogesh commented 4 months ago

Hello @wmdscjhdpy ,

I have not tried myself (as this is not ESP-Hosted issue as such yet),

With help of openAI, I could see possible solution:

Switching from LE Extended Advertising to Standard LE Advertising If LE Extended Advertising is being set prior to using `hcitool leadv` and it's causing issues, you need to ensure the advertising is stopped and properly reset to use standard LE advertising. ### 1. Stop any ongoing advertising Ensure that any ongoing LE Extended Advertising is stopped. You can do this by resetting the advertising settings or disabling the Bluetooth device momentarily. ```bash sudo hciconfig hci0 noleadv ``` Replace `hci0` with your Bluetooth device interface if it is different. ### 2. Reset the Bluetooth device (optional but recommended) Sometimes, resetting the Bluetooth device helps to clear any previous configurations that might be causing conflicts. ```bash sudo hciconfig hci0 reset ``` ### 3. Set the advertising type to standard LE Use `hcitool` to set the device to use standard LE advertising. ```bash sudo hcitool -i hci0 cmd 0x08 0x000A 00 ``` This command sets the advertising parameters. The parameters can vary depending on your specific requirements, so you might need to adjust them accordingly. ### 4. Start standard LE advertising Once the device is configured to use standard LE advertising, start the advertising. ```bash sudo hcitool -i hci0 leadv 3 ``` The `3` parameter here corresponds to `LE_ADVERTISING_IND`, which is the standard advertising type. ### 5. Verify the advertising status You can verify that the advertising is running correctly by checking the device status. ```bash sudo hcitool -i hci0 lescan ``` If the above steps still result in issues, ensure that no other services or applications are configuring the advertising parameters on the Bluetooth device. Conflicting configurations from different services can cause unexpected behavior. If you're using `bluetoothctl` for further configuration, launch it after these steps: ```bash sudo bluetoothctl ``` Then proceed with your usual commands to manage Bluetooth connections and advertisements. By following these steps, you should be able to switch from LE Extended Advertising to standard LE advertising effectively.

But please beware, the hcitool cmd sequence need to be exactly same and it is too strict to maintain. If I get any better way, I will update here.

For now, Can we close the issue? You can reopen anytime, if you have any further doubts/issues.

wmdscjhdpy commented 4 months ago

Thank you for your support, the important information you provided helped me to find out what the key problem was. As a matter of fact my environment did have the normal advertising directive being rejected due to the early use of the extend advertising directive. I tried to disable any user space services related to bluetooth but to no avail. I found my real answer on this problem page: https://stackoverflow.com/questions/75823066/qt-ble-advertising-gives-advertising-error-hci-command-disallowed Just do this:

hcitool cmd 0x03 0x0003

Then you can revert back to being able to use the old broadcast commands. Such as hciconfig hci0 leadv.

mantriyogesh commented 4 months ago

Appreciate for efforts to update the reason and solution, might help someone for same use case.