ESP-IDF v5.1.5 - BLE Crashes after connection parameter update (IDFGH-12607) #13605
Closed
3 tasks done
Assignees
Labels
Resolution: NA
Issue resolution is unavailable
Status: Done
Issue is done internally
Type: Bug
bugs in IDF
Comments
github-actions
bot
changed the title
|
@expresspotato |
Hi @zhp0406, Were you able to determine the root cause and a fix for this issue? |
|
Version 4.3 is no longer under active maintenance, so I've utilized the latest master branch to replicate your issue. I've employed two examples (esp-idf/examples/bluetooth/bluedroid/coex/a2dp_gatts_coex and esp-idf/examples/bluetooth/bluedroid/ble/gatt_client). In the gatt_client example, I irregularly initiate connection parameter updates. No alterations have been made to a2dp_gatts_coex. However, I haven't been able to reproduce the issue you described. log in a2dp_gatts_coex: |
|
Could you test with the latest version to see if the issue persists? If it still exists, could you provide an example that reproduces the problem? |
|
Well there are other issues that are unresolved in 4.4.x, namely #11315, and a few others... Our project is very large, so it's not easy to switch between 4.3.7 and 4.4.x (nor 5.x anything for that matter) without extensive testing. To my knowledge v.4.3.5 didn't have this issue. I see in your test that A2DP, HFP and AVRC aren't connected yet. Can you try and connect those first? |
|
Do you mean this issue only occurs when A2DP, HFP, and AVRC are connected? I don't have A2DP, HFP, and AVRC connected here, only BLE connections. |
|
If you have a demo that reproduces the issue , it would be helpful for me to resolve the problem.” |
expresspotato
changed the title
Upon further observation, the crash occurs during an indicate. The parameters are not yet changed, and an indicate is sent from the ESP32 (GATTS) -> to an Android phone (GATTC) during the update process. One instance: Another: |
|
Hey @esp-zhp , so this is not fixed on v4.4.8... We checked and we really don't do anything bizzare in the code leading up to, or after the connection parameter update. We simply make the request and even wait for the callback with the updated parameters before sending another GATT indicate. Poking around, L2CA_UpdateBleConnParams does return true from the call stack, so it seems like the bug is on Espressif's side. Since the source code is closed, I can't debug it further... What happens in hci_le_rem_con_param_req_reply_cmd_handler? Without HFP connected, I'm unable to reproduce this bug, but I gave up after 50 attempts. With HFP connected, it will crash in in 15 - 20 attempts. Can you try with HFP connected and send data over a ble characteristic through writes? The interesting thing to note is that EXCVADDR is often 0x0014f013 (in my original post and now) along with the following addresses:
|
|
@expresspotato EXCVADDR: 0xfcabba16 Were these two logs generated using different versions of the IDF? |
|
Interesting. So I've updated to v5.1.5 and the issue persists, in a slightly different manner. The stack still refers to |
|
Yes, we haven’t resolved this issue yet. I urgently need a demo from you to reproduce the problem. |
expresspotato
changed the title
espressif-bot
added
Status: In Progress
|
So I've finally had the time to produce an example for you. The code does crash infrequently, so you may have to reboot the device and make several attempts. Overall, there isn't anything special going on.
At ~ 3 minutes: At ~ 4 minutes At 17 sec: |
|
Hi @esp-zhp, any progress on fixing this? |
3 tasks
|
@expresspotato nogoing...will fix |
|
I attempted to reproduce the issue locally following your steps (using the ESP32-PICO-V3-02 chip, revision v3.0, with ESP-IDF v5.1.5), but I couldn't replicate the problem (I’m not sure where the issue lies). Below is the log from my reproduction attempt. Additionally, I reviewed your code: void _task_change_params(void* params) {
uint8_t notify_data[15];
for (int i = 0; i < sizeof(notify_data); ++i) {
notify_data[i] = i % 0xff;
}
while (true) {
_app_bt_request_connection_params_idle();
for (int i = 0; i < 500; i++) {
esp_ble_gatts_send_indicate(gl_profile_tab[PROFILE_B_APP_ID].gatts_if,
gl_profile_tab[PROFILE_B_APP_ID].conn_id,
gl_profile_tab[PROFILE_B_APP_ID].char_handle,
sizeof(notify_data), notify_data, true);
}
vTaskDelay(pdMS_TO_TICKS(1000 * 5));
_app_bt_request_connection_params_active();
for (int i = 0; i < 500; i++) {
esp_ble_gatts_send_indicate(gl_profile_tab[PROFILE_B_APP_ID].gatts_if,
gl_profile_tab[PROFILE_B_APP_ID].conn_id,
gl_profile_tab[PROFILE_B_APP_ID].char_handle,
sizeof(notify_data), notify_data, true);
}
}
vTaskDelete(NULL);
}If you plan to send a large amount of data, I recommend using Meanwhile, I analyzed your coredump again and applied some fixes. You can test whether these are effective: |
|
@esp-zhp thank you. I'll integrate this and test over the next day or so. |
|
Hey @esp-zhp, the bug appears to be fixed. There have been no occurrences over the past 24 hours on my two test devices. Edit: this bug still occurs |
|
Hey @esp-zhp, So looks like the bug is not fixed, but appears at this less frequent stack: |
|
@expresspotato please attch the elf file to help to analyze on the crash. |
|
Hi @BetterJincheng , So I can't upload an elf of our project, but should be able to get you one of the crash within the coming days. In addition to the one above (after the fix) this crash appeared today: |
|
Hey @BetterJincheng , Attached is an example that continues to crash... Installing
What this test does
Crash Stacks There appear to be two distinct stacks ending in similar functions. Stack One Stack Two Files crash-test-esp32.zip
|
|
@expresspotato Using the attached example，I can only find the following error, no above crashes found.
|
|
@expresspotato after a long time, the crash occurs. We are debug on it now. |
|
Hey, @BetterJincheng, thanks for confirming. Usually I'm able to re-produce the crashes within a few minutes. If you see the CPU watchdog timeout, there is something wrong... I would suggest re-setting the board and app and trying again once paired for both BLE and BT Classic. As requested attached is a pre-compiled APK You can also build the Android App from source, its' been hacked away and much of the functionality removed from a much larger application. |
|
@expresspotato We have resolved some issues. Please test with this lib. |
|
Hey @BetterJincheng, Thank you. There was a problem during link time, as a ROM function was missing. I added the one found in master here for The board is flashed, and I'll report back within a few days time. |
|
@expresspotato Sorry for the mistake. |
|
Hey @BetterJincheng , this appears to be fixed 👍 |
espressif-bot
added
Status: Done
RomkaE
pushed a commit
to RomkaE/esp-idf
that referenced
this issue
Apr 1, 2025
1. added a VSC to control whether to initiate lmp_auto_rate
- Closes espressif#15133
2. fixed EA resource cleanup error after SNIFF negotiation failure
- Closes espressif#13605
3. removed an assertion in SCO data TX handler after disconnection
- Closes espressif#15176
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Answers checklist.
IDF version.
v4.3.7, v5.1.5
Espressif SoC revision.
ESP32-Pico-V3-02
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.
None
Development Kit.
LyraT
Power Supply used.
USB
What is the expected behavior?
Not crash
What is the actual behavior?
Crashes
Steps to reproduce.
Debug Logs.
More Information.
Forum topic: https://esp32.com/viewtopic.php?f=28&t=37739
Edit: I've also noticed this issue without changing the connection params myself...
The text was updated successfully, but these errors were encountered: