-
Notifications
You must be signed in to change notification settings - Fork 7.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bluetooth Controller asserts (rwbt.c at line 381) after enable->disable->enable (IDFGH-9469) #10835
Comments
Issue #8405 hits the same assert, but seems unrelated as they don't disable->enable the Bluetooth Controller. |
Hi @mringwal , May I ask if it can be changed to the following way?
Thanks |
Thanks. I will try and let you know. |
Hi @xiongweichao I've copied the the lib from the .zip archive at the indicated location ( $IDF_PATH/components/bt/controller/lib_esp32). I still get the same assert. |
Hi @xiongweichao. This seems to work, thanks! Should esp_bt_controller_mem_release be called a second time if Classic is not used on ESP32:
|
Thanks for checking. Sorry, I must have made a mistake yesterday. Just tried again and the Controller behaves correctly both with enable/disable/enable as well as enable/disabled/deinit/init/enable. Great! Could you ping me here once it was merged into master? Thanks again! |
1. Fixed crash after controller disable and re-enable 2. Fixed the crash caused by processing the HCI_Read_Remote_Extented_Features command in the non-connected state 3. Fixed disconnection due to not handling lmp_unsniff_req in LC_WAIT_SNIFF_SUB_RSP state 4. Fixed crash caused by supervision timeout greater than sniff interval Closes #11164 Closes #10835
1. Fixed crash after controller disable and re-enable 2. Fixed the crash caused by processing the HCI_Read_Remote_Extented_Features command in the non-connected state 3. Fixed disconnection due to not handling lmp_unsniff_req in LC_WAIT_SNIFF_SUB_RSP state 4. Fixed crash caused by supervision timeout greater than sniff interval Closes #11164 Closes #10835
1. Fixed crash after controller disable and re-enable 2. Fixed the crash caused by processing the HCI_Read_Remote_Extented_Features command in the non-connected state 3. Fixed disconnection due to not handling lmp_unsniff_req in LC_WAIT_SNIFF_SUB_RSP state 4. Fixed crash caused by supervision timeout greater than sniff interval Closes #11164 Closes #10835
1. Fixed crash after controller disable and re-enable 2. Fixed the crash caused by processing the HCI_Read_Remote_Extented_Features command in the non-connected state 3. Fixed disconnection due to not handling lmp_unsniff_req in LC_WAIT_SNIFF_SUB_RSP state 4. Fixed crash caused by supervision timeout greater than sniff interval Closes #11164 Closes #10835
Answers checklist.
IDF version.
v5.1-dev-3541-g778aeae99e
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.
ESP32 Lyra T v4.3
Power Supply used.
USB
What is the expected behavior?
I expect the Bluetooth Controller to work after this sequence:
While this enable->disable->enable sequence does not make sense as it is, it's a good test case as it reproduces 100% for me.
In a product, the user would like to disable the Bluetooth Controller to save energy and later enable it again. The crash then happens on the second startup.
What is the actual behavior?
During Bluetooth Host Stack startup, the following assert happens:
[00:00ASSERT_PARAM(2048 0), in rwbt.c at line 381
Guru Meditation Error: Core 0 panic'ed (IllegalInstruction). Exception was unhandled.
Steps to reproduce.
When using BTstack, add the following lines between the existing call to esp_bt_controller_enable and the call to esp_vhci_host_register_callback:
esp_bt_controller_disable();
esp_bt_controller_enable(bt_mode);
Then start any application.
Debug Logs.
More Information.
No response
The text was updated successfully, but these errors were encountered: