You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’m currently working on an ESP32 project using the BLEDevice library in the Arduino environment (PlatformIO). I encountered an issue where BLE pairing frequently fails after repeated connection and disconnection cycles, resulting in an error code 0x66.
This behavior seems similar to an issue previously addressed in ESP-IDF, where the bonding information was being cleared during certain failure scenarios, but the smartphone retained its bond information. In ESP-IDF, this issue was resolved by modifying the bond retention logic under specific error conditions. The fix worked effectively in ESP-IDF (Reference: [ESP-IDF GitHub Issue #14977]
The solution involved ensuring that bond information is not cleared when the failure reason is 0x66 (SMP timeout). In ESP-IDF, the following change was applied to prevent bond clearing for 0x66 errors:
if (sec_event.auth_cmpl.fail_reason!=BTA_DM_AUTH_SMP_CONN_TOUT) {
bta_dm_remove_sec_dev_entry(bda);
}
This was modified to:
if (sec_event.auth_cmpl.fail_reason!=BTA_DM_AUTH_SMP_CONN_TOUT) {
// bta_dm_remove_sec_dev_entry(bda);
}
Now, I’d like to apply a similar solution in the BLEDevice library to resolve the problem in the Arduino environment.
Observations:
I added debug logs to monitor the behavior, and here are the key findings:
Before Connection:
The bond list size was logged after advertising started:
I (48502) BLE_ANCS: advertising start success
I (48502) BONDING_LIST: Bond list size after restart advertises: 3
After Connection:
Successful pairing was observed, with bond information intact:
I (50842) BLE_ANCS: ESP_GATTC_CONNECT_EVT
I (50842) BONDING_LIST: Bond list size after connection: 3
I (47092) BLE_ANCS: pair status = success
After Disconnection:
Bond information was lost after specific disconnection errors:
I (51832) BLE ANCS: pair status = fail
I (51832) BLE ANCS: fail reason = 0x66
I (51842) BONDING_LIST: Bond list size after disconnection: 2
Reconnection Attempts:
Subsequent attempts failed, with persistent bond inconsistencies:
I (52902) BLE ANCS: fail reason = 0x66
I (52912) BONDING_LIST: Bond list size after disconnection: 2
It appears the BLEDevice library does not handle bond retention as effectively as the ESP-IDF implementation.
Questions:
How should this issue be addressed in the BLEDevice library?
Could you guide me on how to modify the bond retention logic to align with the ESP-IDF fix?
Offer to Assist:
If there’s anything else I can provide—such as additional logs, specific test cases, or further debugging details—please don’t hesitate to let me know. I’m happy to assist in any way to help address this issue.
Thank you for your time and support!
The text was updated successfully, but these errors were encountered:
I’m currently working on an ESP32 project using the
BLEDevice
library in the Arduino environment (PlatformIO
). I encountered an issue where BLE pairing frequently fails after repeated connection and disconnection cycles, resulting in an error code0x66
.This behavior seems similar to an issue previously addressed in ESP-IDF, where the bonding information was being cleared during certain failure scenarios, but the smartphone retained its bond information. In ESP-IDF, this issue was resolved by modifying the bond retention logic under specific error conditions. The fix worked effectively in ESP-IDF (Reference: [ESP-IDF GitHub Issue #14977]
The solution involved ensuring that bond information is not cleared when the failure reason is
0x66
(SMP timeout). In ESP-IDF, the following change was applied to prevent bond clearing for0x66
errors:This was modified to:
Now, I’d like to apply a similar solution in the
BLEDevice
library to resolve the problem in the Arduino environment.Observations:
I added debug logs to monitor the behavior, and here are the key findings:
Before Connection:
After Connection:
After Disconnection:
Reconnection Attempts:
It appears the
BLEDevice
library does not handle bond retention as effectively as the ESP-IDF implementation.Questions:
BLEDevice
library?Offer to Assist:
If there’s anything else I can provide—such as additional logs, specific test cases, or further debugging details—please don’t hesitate to let me know. I’m happy to assist in any way to help address this issue.
Thank you for your time and support!
The text was updated successfully, but these errors were encountered: