ble_gattc_disc_all_svcs() fails on ESP32S3 with several peripherals (IDFGH-8664) #10109
Comments
github-actions
bot
changed the title
|
Here is the complete project directory: test_app.zip |
|
I created an identical app using bluedroid and the bahavior is exactly the same, the only difference is the error code that is 0x3B using Bluedroid while it is 7 using NimBLE. |
|
Hi @kojibuta,
Save and quit the menuconfig, build the central, flash, and monitor and you should see log output starting with D |
|
Also, try connecting the peripherals you mentioned with third party BLE testing tools like nRF Connect (as central) and go for service discovery. Please share the logs for the same. |
|
Hi @SumeetSingh19, here are the debug logs running the same source code with two different devices (Blood Pressure Monitor B02T and Thermomether AOJ-20A). Log files 1 and 2 running on ESP32-S3-WROOM-1 (connection failure), log files 3 and 4 running on ESP32-WROOM-32D (successful connect/discovery).
Here are the logs using nRF-Connect on iOS (not really verbose BTW):
Please note that I had to slightly modify the code to start connection with device "AOJ-20A" because the function I think the function should be more "forgiving" with zero-padded advertisements in order to support a wider range of physical devices. You can always think of padding zeros as records having a length of 0. The above advertisement you have 6 records (instead of 3) with lengths 8, 2, 9, 0, 0, 0. Here is the modified main.c file: test_app.zip |
|
Hi @SumeetSingh19, Apparently the controller is sending a different HCI command to the host and this triggers the error.
I tried running the same app on Unexpected Maker TinyS3 development board with ESP32-S3FN8 MCU and I get the same results. I would like to know if you plan to address this problem in the near future, otherwise I must go back to ESP32-WROOM-32E module for my device. I would like to use the new ESP32-S3-WROOM-1 because it has better overall performances but I need to support several BLE devices that do not work properly with ESP32-S3. |
|
Hi @kojibuta, the controller doesn't send different HCI commands, actually, the first byte of the command is different because the connection handles in the two chips start at 0 on esp32 and 1 on esp32s3. |
|
HI @kojibuta i checked your logs and compared it with success logs . The failure scenario in your case is that even though connection packet has been sent, the actual connection is not happening. As seen in logs, we see a disconnect with reason code 0x3E. This basically points that the actual over the air connection with remote is failed. This behaviour also points that this may be specific in the communication of S3 and the particular remote device. Am sure, S3 would be working with other devices , even in your tests ? I wanted to check, if it is feasible for you to get a OTA log to check the packets ? Since from host side, we have already posted the command with valid parameters. |
|
I run into this issue while porting an existing firmware from ESP32 to ESP32-S3. The firmware has been working very well on a custom BLE/MQTT gateway I designed for several years. I am in the process of re-designing the custom gateway and I would like to upgrade to ESP32-S3. Unfortunately some of the BLE peripherals my customers are actively using do not work with ESP32-S3.
The ESP32-S3 board and my firmware both work well with many devices by the way. But not with all of them. A subset of the devices I must support is not working. Since all devices work well using the same firmware on ESP32 (instead of ESP32-S3) I thought it could be a BLE stack implementation bug specific to ESP32-S3.
I really would like to send you all the logs you need, but I don't know how/where to get a OTA log. |
|
Hi @SumeetSingh19,
Do you mean it can be a RF related problem? |
So, we need OTA logs to be sure of this, and hence I requested the logs.
Well, I believe you are using NimBLE as a stack for both chips. So, eventually, it should not matter, as these are standalone BLE operations.
The underlying CPU has Xtensa architecture support (one is LX6 while the other is LX7). So they are the same architecture. |
|
Hi @SumeetSingh19,
I don't know how to get the OTA logs. Can you please tell me how to do it? |
|
Hi @kojibuta , |
|
Hi @SatishSolankeEsp, Apparently I am using controller lib 76c24c9 and IDF release/v5.0. The issue always occurs immediately. Connection is never established, no matter how many times I try. The scan is canceled before initiating the connection. Here is the nimble API function call sequence: The device supports Bluetooth LE 4.0. No other specs are available. The test_app initiates connection as soon as it finds a device with name "AOJ-20A". |
|
Hi @kojibuta , As discussed earlier could you please reproduce the issue of connection fail with debug controller lib and the provided patch to provide us the logs? |
|
Hi @SumeetSingh19,
I don't see the attachments. |
|
@kojibuta , you should see a zip file now. It contains the two files. |
|
Hi @SumeetSingh19, sorry but I don't see any attchment. Here is the screenshot of my github page.
|
|
Hi @kojibuta , |
|
Hi @SumeetSingh19, thank you, now I can see it. Thank you. |
|
Hi @SumeetSingh19, I completed the tests you suggested. Unfortunately the libbtdm_app.a file you sent seems to cause system failure on the ESP32S3:
I performed three tests:
Here are the log files of each of the three tests. Patch only Controller lib only Patch + controller lib I deleted and re-installed the SDK from scratch so to have a "clean" installation. |
|
Hi @SumeetSingh19 , I think the controller init failed depends on bt controller lib compile version mismatch. The latest "release/v5.0" SDK version comes with 80abacd:
The modified lib you sent instead is version 76c24c9 (as per my previous post). Maybe you can point me to the correct commit hash to use the same source code as the modified library version you sent. |
|
Hi @kojibuta , |
|
Hi @kojibuta , BT controller compile version [ae171b2] Thanks, |
|
Hi @SumeetSingh19, Please find attached the log file you requested using the modified controller lib, plus the log using the original lib for completeness. Modified BT controller lib Un-modified (original) BT controller lib Let me lnow if I can do something else to help. |
|
Hi @kojibuta , |
|
Here is the log without the patch (fresh clone from github) and modified BT controller lib. The connection attempt is at the end of the log file, it starts after the following lines: |
|
HI @kojibuta , Please try this fix by putting this controller lib of esp32s3 on the tip of release/v5.0.
Controller lib HEAD TIP: (controller commit id 80abacdd)
Replace this attached lib in the below path:
Let me know the result and share the OTA as well. Thanks, |
|
Great news! Your fix is working perfectly. All my ESP32-S3 boards successfully connect to the peripherals and perform the service discovery. Thank you very much for your support. Please find below some logs and an OTA capture file recorded during some successful connections. [log file] [log file debug level] [wireshark OTA capture] |
|
Apparently the FIX causes a regression. Sorry for the bad news. Using the library with your fix solves connection problems with several devices (e.g. "AOJ-20A"). Unfortunately other devices (e.g. "DuoEK 1429"), that are working without the patch, with the fix cannot connect anymore. What I can see in the debug logs is that the connection is setup correctly but the "exchange mtu" procedure fails. The connect is retried 3 times but MTU exchange always fail and the disconnect event is generated. To better clarify:
Please find attaches some logs, hope they can help. [ESP32-S3 - using lib fix - device "AOJ-20A" successful connect] [ESP32-S3 - using lib fix - device "DuoEK 1429" connect error (log+air)] [ESP32-S3 - stable/v5.0 - device "AOJ-20A" connect error] [ESP32-S3 - stable/v5.0 - device "DuoEK 1429" successful connect] I also found some errors with service discovery using the stable/v5.0 SDK version. After successful connection and MTU exchange, service discovery fails and causes ESP32-S3 to hang. Maybe this is all part of the same problem. [ESP32-S3 - stable/v5.0 - device "DuoEK 1429" successful connect + service discovery error (log+air)] |
|
Hi @kojibuta , |
|
Hi @kojibuta , |
|
I already tested the lib S3_fix_conn_fail.zip with several devices supported by my IoT gateway app. It is working with all of them. Devices tested so far:
I will make some more tests in the upcoming days and let you know the results. Thank you very much for your support. |
|
I also run the test_app (NimBLE + ESP32-S3) and the service discovery error with device Viatom DuoEK is still present. Using Bluedroid instead I get no error at all and all devices work correctly. Apparently your fix is working perfectly with Bluedroid (all devices working) but not with NimBLE (some device still not working). Let me know if I can help you sending more debug/OTA logs. |
|
Hi @kojibuta , |
|
After extensive testing I can confirm that all the test devices I have are currently working with ESP32-S3 and Bluedroid. I can also confirm that roughly a half of the same devices is not working as expected using NimBLE instead. Please find attached some logs files both of working and not working devices (2+2). NOTE: the device E66 is a Fitness Bracelet using Nordic nRF52832 chip. It is a very common chip so I think it is important to find out why NimBLE is not working with this device. [Successful tests] [Failed tests] |
|
Hi @kojibuta , @SumeetSingh19 , |
espressif-bot
added
Resolution: Done
|
I tried compiling my firmware using version ESP-IDF v5.0.2 and ESP32-S3 does not work yet. Do you think your patch to the bluetooth controller lib will be merged into the master branch any time? |
|
Hi @kojibuta , |
|
HI @kojibuta , As per Bluetooth specification, we have selected the correct algorithm. I have come up with a solution for it, the remote device fails to connect or the remote device supports ble4.2,4.0 for them you can disable the CONFIG_BT_BLE_50_FEATURES_SUPPORTED flag in the IDF menu config and re-try to connect. Please let me know if these procedures are useful for you. Thanks, |
|
Unfortunately disabling CONFIG_BT_BLE_50_FEATURES_SUPPORTED does not work for me.
|
|
Hi @kojibuta , Our fix is merged with the below commit id : Thanks, |
|
Hi @SatishSolankeEsp, |
|
HI @kojibuta |
|
Hi @SatishSolankeEsp, |
|
Hi @kojibuta , Thanks, |
|
At the moment I am using the latest master branch, because of another bug in the Wi-Fi stack fixed recently #12478. |
|
Hi @kojibuta , let me know the result. |
|
The lib fix solves the issue with channel select algorithm on esp32c6. Now I am able to connect to a 4.0/4.2 device successfully. Does the fix automatically select the correct channel select algorithm based on the device? Thank you |
|
Hi @kojibuta , |
Has these fixes been merged? |
|
We have merged the change on versions 5.1, 5.2, and the master branch.
|
Answers checklist.
IDF version.
ESP-IDF v4.4.2-388-g755ce1077d
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.
No response
Development Kit.
Custom board
Power Supply used.
USB
What is the expected behavior?
When using NimBLE (BLE central role) on ESP32-S3 it is not possible to discover services on some peripheral devices. The same code runs smoothly on ESP32 without errors.
After connection is established with a peripheral (event
BLE_GAP_EVENT_CONNECTreceived withevent->connect.status == 0) callingble_gattc_disc_all_svcsshould result in invokation of callback functionble_gatt_disc_svc_fnwitherror->status == 0.What is the actual behavior?
When running the code on ESP32-S3, after connection is established with a peripheral, calling
ble_gattc_disc_all_svcsresults in immediate invokation of callback functionble_gatt_disc_svc_fnwitherror->status == 7.Steps to reproduce.
ESP32-S3 logs (SleepO2 device OK, B02T device KO)
ESP32-S3 board + SleepO2 device: esp32-s3-peripheral-1.log
ESP32 board + B02T device: esp32-s3-peripheral-2.log
ESP32 logs (SleepO2 and B02T device OK)
ESP32 board + SleepO2 device: esp32-peripheral-1.log
ESP32 board + B02T device: esp32-peripheral-2.log
Debug Logs.
More Information.
Error always occur using some peripheral devices, but not with every device.
Error occurs using ESP-IDF release/v4.4, release/v5.0 and latest versions.
Some peripheral causing the error are:
Some peripheral working without errors are:
The text was updated successfully, but these errors were encountered: