BLE service discovery fails on low BLE connections : lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2) (IDFGH-6671) #8303
Comments
github-actions
bot
changed the title
|
This is not linked to my custom service, the error occurs while discovering a single standard service (0x1800, Generic Access) : |
|
I found that the timing between "GATT procedure initiated: discover service by uuid" and "Error: Service discovery failed" is always equal to 6 times the max connection interval. This looks like the connection is created and not established ? Quoting "Intro to Bluetooth Low energy" : "The one exception - where the supervision timeout does not apply - is after a connection is created, but not yet established. In this case, the master will consider the connection to be lost if it does not receive the first packet from the slave within: 6 * connInterval" |
|
It seems to be indeed that the peripheral doesn't always receive the connection packet. The event BLE_GAP_EVENT_CONNECT should only be sent if the connection is established, meaning that we received a response from the peripheral. Today, it seems that this BLE_GAP_EVENT_CONNECT is sent to controller as soon as the connection packet is sent, without waiting for a response. |
|
After finer analysis and data from our installed devices, I think there really is a an issue inside the closed-source Bluetooth part of ESP-IDF (https://github.com/espressif/esp32-bt-lib), with the HCI layer randomly dropping or missing the connection packet. I have added a connection retry to 5 times, and some devices have this behaviour now :
It happens on devices with RSSI approximatively below -88, whereas esp should work fine until -94. Could someone from Espressif look into this ? It seems that it's hitting a variety of customers, applications and boards, and of SDKs (ESP-IDF, Micropython, Arduino). |
|
I have already tried with ESP-IDF v4.4 + manually pulling latest development versions of https://github.com/espressif/esp32-bt-lib and https://github.com/espressif/esp-nimble |
|
@rahult-github please take a look |
|
i got this issue too, can anyone tell me how to fix it? now i can only increase the connect retry times |
|
Oh, this is still not resolved? Could you please write down the version numbers you use? |
i am using esp-idf 4.3 stable version. |
|
I also have problem about the error to communicate with xbox controller but it does not occur with using ESP32C3. |
|
@QuentinFarizon Do you have any updates about this problem? |
|
@mdenissov We are still hit hard by this bug, in production. Since then, we updated to esp-idf v5.0, which seemed to reduce the frequency of the errors, but we still encounter it a lot. There is some new information on this ticket : #5105 |
|
same issue here, we are connecting from an ESP32 (with an external puck antenna) to a Nuki smart lock. I do not know how to use wireshark but it is definetely related to rssi as when I move the lock closer to the esp32 the problem reduces (I see less retries) Hope this can be resolved soon... |
|
@ocESP any update on this? |
|
Having the same issue. Using NodeMCU 1.1v ESP32-S2 model. |
|
If it helps anyone Board ESP32 Dev Board CH340 USB-C.
After these changes I got a stable and fast Bluetooth connection. Also some time after flash via USB and restart, have problem with bt connetion, but if unplug usb and restart board with external power supply all works well. So board have some problem with CH340 ic. |
So I have done two things, do not know which of them fixed it:
Either way, my code now appears to work. |
|
It seems that calling service discovery too fast can cause such issue. Bluetooth connection needs some time to settle. Additionally BLE expect MTU negotiation to happen. So if you start sending service discovery before MTU, then it might cause such issue. I had the same issue and fixed it by waiting for BLE_GAP_EVENT_MTU: static int ble_client_gap_event(struct ble_gap_event *event, void *arg) {
ble_client *client = (ble_client *) arg;
ESP_LOGD(TAG, "gap event: %d", event->type);
switch (event->type) {
case BLE_GAP_EVENT_CONNECT: {
int status = event->connect.status;
if (status == 0) {
ESP_LOGI(TAG, "connection established");
client->conn_handle = event->connect.conn_handle;
} else {
ESP_LOGE(TAG, "connection failed. ble code: %d", status);
client->semaphore_result = ble_client_convert_ble_code(status);
client->connected = false;
xSemaphoreGive(client->semaphore);
}
break;
}
// notify connected only after MTU negotiation completes
case BLE_GAP_EVENT_MTU: {
ESP_LOGI(TAG, "MTU negotiated");
client->semaphore_result = ESP_OK;
client->connected = true;
xSemaphoreGive(client->semaphore);
break;
}
default:
break;
}
return 0;
} |
Environment
Problem Description
I'm using Nimble on a esp32 (ESP32-PICO-V3) acting as central, connecting to a BLE peripheral (nRF 52832).
This project is used in production on a few hundreds devices.
When the peripheral is close, everything works fine, connect, discovery, writes, reads, and does long exchanges of data.
When the device to connect to is far (RSSI < -86), sometomes all goes well, but I often (randomly) get this error :
See full log below
I have tried increasing connection max interval and supervision timeout, on the central (initial parameters) and peripheral, with no luck.
I have disabled data length extension in Nimble, with no luck.
Note that this error line happens relatively quickly after service discovery starts, and is not impacted by connection intervals, which does not point to a timeout.
Expected Behavior
No error, service discovery proceeds correctly
Actual Behavior
Disconnect during service discovery
Steps to reproduce
I have separated the two boards by a few meters, separated by a wall, to be able to reproduce the issue.
The more the RSSI drops, the more issue I encounter
Code to reproduce this issue
My code is based on the blecent example (examples/bluetooth/nimble/blecent/main)
I'm just pasting here the part where we launch the service discovery when connnected :
Debug Logs
When error occurs :
When all goes well :
The text was updated successfully, but these errors were encountered: