BT Controller - Stops Scanning or responding after random amount of time (IDFGH-1781) #4001

0neblock · 2019-09-03T01:48:21Z

Brief

I have been having a problem with the Bluedroid BT Controller Scanning function for a few weeks now, and after trying many different things, I am stuck and am not sure what else I can try.
The crux of the issue is that the BLE Scanning feature will work for a large amount of time - up to 3 days, then just fail silently, with the whole BT controller seemingly shutting down.

Problem Description

I have a BLE Scanning app that is working well for the most part. It spends most of its time performing an active scan for other BLE devices that are advertising a service UUID and some custom manufacturer data. It receives an advertisement from a sensor around every 1 second, but I can have anywhere from 1-10 sensors within range at any one time.

After a completely random period of time, sometimes 20 minutes, sometimes 3 days. The App will stop receiving ESP_GAP_SEARCH_INQ_RES_EVT events from the bt layer, even though it should still be receiving advertisements form multiple devices, with no indication from any underlying BT Controller debugging that anything has happened. This happens no matter how many sensors I have within range of the ESP, advertising the device, it even happens when I have no sensors advertising, and the general BVLE background advertisements are relatively low.

The free heap memory of the app stays the same (~140kB free memory at any one time), so I can rule out a memory leak on the app side, and the rest of the application keeps running normally, albeit with more computation time from the RTOS (indicated by a loop counter that increases when this error happens), So clearly some of the BT Tasks have stopped running.

When the error happens, I can also see that the ESP itself DOES STOP performing Active scanning, as The sensors I use flash an LED whenever they receive a SCAN_REQUEST from the ESP32 Hardware MAC Address, and this stops happening as soon as the error starts.

If I try and recover from the error, by issuing a command such as esp_ble_gap_start_scanning() - which responds ESP_OK, I get a HCI timeout error printed: BT_HCI: command_timed_out hci layer timeout waiting for response to a command. opcode: 0x200c.
At the moment, trying to perform a bt command after the error, and getting this response, is the only indication from the application that something has gone wrong.

I am not using any WiFi functions, so to reduce memory footprint and file size, I have changed the linker script to only include the following libraries in the component.mk of esp32:
core rtc phy instead of the usual: core rtc net80211 pp wpa smartconfig coexist wps wpa2 espnow phy mesh

Coredump

coredump
This is a coredump taken about 20 minutes after the error occured. I forced this core dump to log by deliberately throwing an IntegerDivideByZero Exception in another task. My hope here is that it saved the task state of the BT tasks, which your team can use internally to see the task state. If you require My APP ELF I can provide this by email.

Debug Log

This is a log showing the lack of errors I receive when the error happens. As you can see, the application was running for 2.5 days before the error occured. The 'BMS' TAG is my application, and the 'Scanning started' and 'scanning stopped' logs are when my app receives the ESP_GAP_SEARCH_INQ_CMPL_EVT and ESP_GAP_BLE_SCAN_START_COMPLETE_EVT events respectively. In this application, I start a esp_ble_gap_start_scanning operation of 30 seconds, and when I receive a ESP_GAP_SEARCH_INQ_CMPL_EVT event, i set a flag to restart the esp_ble_gap_start_scanning of 30 seconds, in a cycle. Although as discussed later, I have tried changing this interval to anywhere from 30 seconds to 5 minutes, and I have also tried setting the interval to 0 for unlimited, so I only call the start_scan once.
In this instance, my pplication received the ESP_GAP_SEARCH_INQ_CMPL_EVT event, so set a flag internally to call esp_ble_gap_start_scanning(30) again, which responded with ESP_OK, but I never received the ESP_GAP_BLE_SCAN_START_COMPLETE_EVT, and about 8 seconds later, I see an error log of command timeout.

I (210356607) BMS[scanning]: Scanning Stopped
I (210356607) BMS[scanning]: Scanning started
I (210363327) main: HEAP - free: 140560, largest_block: 98108 | PSRAM - free: 3451316, used: 202360, attempted: 981230 | pps: 21, lps: 248
I (210373357) main: HEAP - free: 140560, largest_block: 98108 | PSRAM - free: 3451316, used: 202360, attempted: 981230 | pps: 20, lps: 249
I (210383367) main: HEAP - free: 140560, largest_block: 98108 | PSRAM - free: 3451316, used: 202360, attempted: 981230 | pps: 19, lps: 247
I (210386607) BMS[scanning]: Scanning Stopped
I (210386617) BMS[scanning]: Scanning started
I (210393387) main: HEAP - free: 140560, largest_block: 98108 | PSRAM - free: 3451316, used: 202360, attempted: 981230 | pps: 21, lps: 248
I (210403407) main: HEAP - free: 140560, largest_block: 98108 | PSRAM - free: 3451316, used: 202360, attempted: 981230 | pps: 19, lps: 248
I (210413457) main: HEAP - free: 140560, largest_block: 98108 | PSRAM - free: 3451316, used: 202360, attempted: 981230 | pps: 19, lps: 249
I (210416617) BMS[scanning]: Scanning Stopped
I (210423487) main: HEAP - free: 140560, largest_block: 98108 | PSRAM - free: 3451220, used: 202452, attempted: 981230 | pps: 17, lps: 250
E (210424617) BT_HCI: command_timed_out hci layer timeout waiting for response to a command. opcode: 0x200c
I (210433497) main: HEAP - free: 140560, largest_block: 98108 | PSRAM - free: 3451220, used: 202452, attempted: 981230 | pps: 25, lps: 250

sdkconfig

Scanning Configuration Used

These are the configurations currently in use, but as you'll see below I have tried many different

static esp_ble_scan_params_t logging_ble_scan_params = {
    .scan_type              = BLE_SCAN_TYPE_ACTIVE,
    .own_addr_type          = BLE_ADDR_TYPE_PUBLIC,
    .scan_filter_policy     = BLE_SCAN_FILTER_ALLOW_ALL, 
    .scan_interval          = 0x100,
    .scan_window            = 0x100,
    .scan_duplicate         = BLE_SCAN_DUPLICATE_DISABLE
};

Changes Attempted

Below is a list of sdkconfig changes of application setup/operation changes that I have tried, with no success , the same thing occurs.

Unlimited scanning timeout - when done this way, I never even get an indication of hci_layer_timeout, because i never try to run another esp_ble_gap_start_scanning call, so the bt controller will fail silently
Turning CONFIG_BLUEDROID_MEM_DEBUG ON - There is no debugging information around the time the error happens
CONFIG_BT_BLE_DYNAMIC_ENV_MEMORY ON/OFF
CONFIG_BT_ALLOCATION_FROM_SPIRAM_FIRST ON/OFF
CONFIG_BLE_HOST_QUEUE_CONGESTION_CHECK ON/OFF
Scanning interval/window change to many different values: 0x100/0x50, 0x200/0x50, 0x1000/0x100, and a few more.
180 second scanning timeout - This seems to make the error happen quicker, although that may be placebo as I only tested a few times.
Increase CONFIG_BTC_TASK_STACK_SIZE and CONFIG_BTU_TASK_STACK_SIZE
Not calling esp_bt_controller_mem_release(ESP_BT_MODE_CLASSIC_BT) (which I usually call before enabling anything.
Enabling/disbling WiFi coexist (I am not using WiFi function at all

If there is anything else I should try, please let me know.

Apologies for the large Github issue, this error has been troubling me for some time and I would like to know what I can try next. Thank you.

Environment

Key	Value
Development Kit	Custom Board
Module or chip used	ESP32-WROVER-32
IDF version	`91f29be` - tracking release/v3.3
Build System	Make
Compiler version	crosstool-ng-1.22.0-80-g6c4433a
Operating System	macOS
Power Supply	external 3.3V

The text was updated successfully, but these errors were encountered:

0neblock · 2019-09-08T11:06:34Z

One thing to note which I just thought of, I am compiling with Arduino-ESP32 as a component.
I am not sure if that would affect anything as I am using esp-idf for all the bluetooth-related functionality, as i found the BLE library in Arduino a bit too resource-intensive.

0neblock · 2019-09-20T03:07:52Z

Hey @igrr (Don't know who else to @), woukd someone be able to have a look at this, this issue is still ongoing for me.

gengyuchao · 2019-09-24T07:59:24Z

Hello, sorry for the late reply. Do you added a lot of printing in esp_gap_cb? I recommend that you turn off some unnecessary printing, such as remove the print of device name and address from when scanning. This is not the final solution, but try to see if the issue is resolved.Thank you.

0neblock · 2019-09-25T00:21:31Z

Hi @gengyuchao, thanks for your reply.
I do no printing in esp_gap_cb, and i also keep my processing time to a minimum, by adding most events to a queue via xQueueSendFromISR and processing them in another thread.

gengyuchao · 2019-09-25T03:30:26Z

According to your description, I have not been able to reproduce the problem. Can you give me a sample code of your problem? So I can try to track this problem, thank you.

0neblock · 2019-09-25T03:44:34Z

Hi @gengyuchao,
The problem can take anywhere from 20 minutes to 3 days to happen, and my app is not able to be shared in its current state, however i can share the elf to analyse the coredump if you like.

I will try to build a smaller program that can reproduce the issue.

It seems that the error is that the pre-compiled bt lib is the component that is crashing.
Is there anyway i can diagnose the current state of the esp32 bt lib when i detect an error?

0neblock · 2019-10-29T22:59:15Z

Seems to be related to #4196

0neblock · 2019-11-19T05:43:27Z

Hi @prasad-alatkar is there any update on this or Issue #4196 ?
We are about to enter production and this is still an ongoing issue for us, we are having to call esp_restart every time the BT Controller fails, which is not ideal.

Sushant-Espressif · 2019-11-19T10:30:24Z

@one

Hi @prasad-alatkar is there any update on this or Issue #4196 ?
We are about to enter production and this is still an ongoing issue for us, we are having to call esp_restart every time the BT Controller fails, which is not ideal.

We are working on BT controller firmware fix for the issue. In BLE scan scenario, couple of issues are observed where BT controller reboots with controller level malfunction error code OR just stops responding without any known error. Issue is related to the handling of scan reports in BT controller when there are large number of scan reports in short frame of time. We will release the further details and updated bt lib as soon as possible.
Thanks.

0neblock · 2019-11-19T10:35:13Z

Thanks for your prompt response, good to know you have identified the issue source. Look forward to applying a fix!

0neblock · 2019-12-11T06:31:00Z

Hi @csushantk
I noticed that a few commits were pushed to the Github repo recently, can you please confirm if your fix for this issue was included?

I am tracking release/v3.3 for my IDF toolchain.
I am testing this latest release now.
Thanks.

pschlang · 2020-01-13T09:38:08Z

Observing the same issue with v4.0-beta2. Any news here @csushantk ? This is really urgent for us.

plebed · 2020-02-14T10:08:40Z

The same issue in v3.3.1.
Like a ugly workaround, we restart the chip if scan_result->scan_rst.num_resps (in ESP_GAP_SEARCH_INQ_CMPL_EVT) not changed during five scans.

It is strange that scan_result->scan_rst.num_resps is not reset between scans.

0neblock · 2020-06-19T01:52:06Z

Any updates from anyone on this bug? Still an issue with the latest release/v3.3 branch

plebed · 2020-06-22T13:18:39Z

I update out firmware to v4.1 (this error did not reproduce in v4.1).

GianlucaLoi · 2020-09-16T07:01:47Z

Hello @Sushant-Espressif ,

I'm having the same issue of @0neblock with the same "fw environment". I'm using ESP-IDF v4.3-dev-907-g6c17e3a64.
Any update about this problem?

Regards,

Gianluca.

Sushant-Espressif · 2020-09-16T07:17:34Z

@GianlucaLoi @0neblock In our local setup, with Bluedroid Host, we are not able to reproduce the issue of "BLE stops scanning randomly" (tested for one week continuously).
Can you please provide more details to reproduce this issue?

Are there excessive prints in your application?
Is application task set to higher priority and hogging the CPU?
Is it possible to share any other details about the application so that we can quickly reproduce the issue?

GianlucaLoi · 2020-09-16T07:30:51Z

@GianlucaLoi @0neblock In our local setup, with Bluedroid Host, we are not able to reproduce the issue of "BLE stops scanning randomly" (tested for one week continuously).
Can you please provide more details to reproduce this issue?

Are there excessive prints in your application?

Is application task set to higher priority and hogging the CPU?

Is it possible to share any other details about the application so that we can quickly reproduce the issue?

Hello @Sushant-Espressif ,

Thanks for the response.

> 1. Are there excessive prints in your application?
I have very few prints when my fw is ongoing. At point 3 you can see an example.

> 2. Is application task set to higher priority and hogging the CPU?
Could you be more specific?

> 3. Is it possible to share any other details about the application so that we can quickly reproduce the issue?
In my application I have WiFi (STA mode), MQTT (no SSL) and BLE.
What my FW does is:

At the startup it waits for a WiFi Smart Configuration,
Once is connect to the WiFi, MQTT and BLE task will be initialized and a periodic active scan starts (period about 5seconds) and a task (TASK1) is created to manage the scan data of ble to send the data by MQTT
If there is any data that needs to be publish, MQTT publish function is called by the TASK1
The FW so remains scanning and sending with 5 second period. An example of prints is shown below

I (1231732) TASK1: [APP] Free memory: 4220620 bytes
I (1231746) BLE: Scan started
I (1231833) MQTT: MQTT_EVENT_DATA
I (1236748) BLE: Scan restarting...
I (1236748) TASK1: [APP] Free memory: 4222208 bytes
I (1236751) BLE: SCAN PARAM SET COMPLETE
I (1236763) BLE: Scan started
I (1241765) BLE: Scan restarting...
I (1241768) BLE: SCAN PARAM SET COMPLETE
I (1241773) MQTT: sent publish successful, msg_id=0
I (1241773) TASK1: [APP] Free memory: 4220496 bytes
I (1241815) MQTT: MQTT_EVENT_DATA
E (1249770) BT_HCI: command_timed_out hci layer timeout waiting for response to a command. opcode: 0x200c

If you need more information, I will be glad to give them.

Regards,

Gianluca.

GianlucaLoi · 2020-09-17T11:36:51Z

Hello @Sushant-Espressif ,

Do you have any update about this problem?

EDIT:
@igrr do you have any solution about this problem? I pulled the ESP-IDF v4.3-dev-1197-g8bc19ba89 where there are a lot of bufixs on bluetooth but I still have this problem.

Regards,

Gianluca.

chhajedji · 2020-10-19T15:16:58Z

Hi @GianlucaLoi
Can you tell us that if you are using advertising report flow control and scan duplicate filtering options?
These options can be found in sdkconfig under name CONFIG_BTDM_BLE_ADV_REPORT_FLOW_CTRL_SUPP and CONFIG_BTDM_BLE_SCAN_DUPL.

GianlucaLoi · 2020-10-19T16:00:39Z

Hello @chhajedji
They are both set as YES.
Regards,
Gianluca.

chhajedji · 2020-10-20T05:19:01Z

Hi @GianlucaLoi
We tried to reproduce your issue, but we didn't get any success. Can you follow below steps and share the logs with us.

Apply this patch present in the attached tarball and also replace the bt lib at $IDF_PATH/components/bt/controller/lib/libbtdm_app.a by the lib in tarball.
Run your program and when crash occurs, store all the logs in a file.
This tarball contains a patch for esp-idf and a bt lib. These are not official versions, but just to get the logs of exact scenario.
gh_timeout.tar.gz

GianlucaLoi · 2020-10-20T10:51:11Z

Hello @chhajedji

I performed your steps but, in the Linker section, I obtain these errors from the libbtdm_app.a:

undefined reference to `ke_task_env'
undefined reference to `ke_handler_search'
undefined reference to `ld_pscan_frm_cbk'

How can I solve them?
Regards,

Gianluca.

chhajedji · 2020-10-20T12:32:35Z

Can you try doing a git fetch and git submodule update --init --recursive.
Since you are using current master branch and it is getting updated frequently, You will have to do a git checkout 0289d1cc81c210b719f28c65f113c45f9afd2c7b as I have created given patch on this commit.

Also note that you will have to first update submodules (git submodule update --init --recursive) then replace given library. And similarly git fetch and git checkout 0289d1cc81c210b719f28c65f113c45f9afd2c7b and then apply given patch.

GianlucaLoi · 2020-10-22T07:20:42Z

Hello @chhajedji

I'm still doing your test because I have to adapt some function to your repository to work well.
In the meanwhile I tested the ESP-IDF v4.1 and I see this problem also with that version.

One more information to understand the problem (maybe):
Because I need an active scan, every 5 seconds I re-set the scan params. When this phase is complete I restart the scanning.

`
static esp_ble_scan_params_t ble_scan_params = {
		.scan_type              = BLE_SCAN_TYPE_ACTIVE,
		.own_addr_type          = BLE_ADDR_TYPE_PUBLIC,
		.scan_filter_policy     = BLE_SCAN_FILTER_ALLOW_ALL,
		.scan_interval          = 0x50,
		.scan_window            = 0x30
};

...
case ESP_GAP_BLE_SCAN_PARAM_SET_COMPLETE_EVT:                	
		if(param->scan_param_cmpl.status == ESP_BT_STATUS_SUCCESS)
		{
			ESP_LOGI(BLE_LOG_TAG,"SCAN PARAM SET COMPLETE");
			esp_ble_gap_start_scanning(5);
		}
		else
		{
			ESP_LOGE(BLE_LOG_TAG,"SCAN PARAM SET NOT COMPLETE");
		}
		break;
	
...
case ESP_GAP_SEARCH_INQ_CMPL_EVT:
                ...
		esp_ble_gap_set_scan_params(&ble_scan_params);
		break;
...
`

Regards,

Gianluca.

chhajedji · 2020-10-22T09:14:09Z

Hi @GianlucaLoi

I am also testing with this parameters and see if I can reproduce it. In case you get the crash, please share the logs.

chhajedji · 2021-05-18T14:52:53Z

Hi @vbvchauthmal,

I will trying to recreate the issue. Although I tried same earlier for @GianlucaLoi and before I could recreate it, changing some parameters helped for them. Please share some more details about your failing scenario through which I can reproduce it.

Which commit id are you using for your application?
What exactly are you doing in your application (scanning/advertising/both, anything else also) and what are the parameters for the same (scan params, adv params)?
Which idf example will most closely resemble your application and what are the changes in it to emulate your scenario. Or if you can share your application, that would be better.
How many devices are there in the vicinity and what are they doing (how many advertisers and scanners nearby)?
How long does this issue take to occur for your case and does this time vary?

Also please provide any other information you feel which could be helpful to recreate or solve this issue.

vbvchauthmal · 2021-05-21T14:54:49Z

Hi @chhajedji

Hi @vbvchauthmal,

I will trying to recreate the issue. Although I tried same earlier for @GianlucaLoi and before I could recreate it, changing some parameters helped for them. Please share some more details about your failing scenario through which I can reproduce it.
* Which commit id are you using for your application?

I am using ESP-IDF version v3.3.5 (commit id : 03810c4) after your suggestion, earlier I was using v3.3.1 (commit-id : 143d26a )

* What exactly are you doing in your application (scanning/advertising/both, anything else also) and what are the parameters for the same (scan params, adv params)?

I am doing BLE scanning and below are the scan parameters set in my source code :

ble_scan_params = {
    .scan_type              = BLE_SCAN_TYPE_ACTIVE,
    .own_addr_type          = BLE_ADDR_TYPE_PUBLIC,
    .scan_filter_policy     = BLE_SCAN_FILTER_ALLOW_ALL,
    .scan_interval          = 0xF0,                         // Interval between the start of two consecutive scan windows. Dec(0xF0) = 240 x 0.625 = 150ms
    .scan_window            = 0xF0                          // The duration in which the Link Layer scans on one channel. Dec(0xF0) = 240 x 0.625 = 150ms
};

* Which idf example will most closely resemble your application and what are the changes in it to emulate your scenario. Or if you can share your application, that would be better.

The idf example closely resemble with my application is gattc_multi_connect. This application extended with setting of BLE GAP security parameters and supporting interfacing of five BLE peripheral devices. At a time only one BLE peripheral will be allowed to connect when its broadcasting is captured to get sensor readings i.e. through BLE notifications/indications.

* How many devices are there in the vicinity and what are they doing (how many advertisers and scanners nearby)?

Till now we have deployed 6000 of our ESP32 based platform with this developed firmware and all must have different numbers of BLE devices in vicinity which can be advertisers or scanners. Most of these deployed showing this issue.

* How long does this issue take to occur for your case and does this time vary?

Its occurring at random sometimes it will arise after week or sometimes it will take few minutes or hours.

Also please provide any other information you feel which could be helpful to recreate or solve this issue.

Query :

Is there any API (for checking the Bluetooth radio / BLE scanning status) which I can execute for knowing the BLE scan is stopped or hanged? I observed sometimes this issue reproduced without any BT_HCI errors in log, so wanted to get status of underlying BLE scan so I can reset bluetooth instead of executing esp_restart().
What is the proper sequence to reset bluetooth ?

Rokachy · 2021-06-10T13:03:35Z

We are facing the same issue
We are working with 4.2.1 release, we tried also v4.3-beta3 tag and also v4.4-dev tag and the issue is also there.
When this issue occur, BT radio status looks good no error reported so software cannot detect this...
We tried many option to reset BT only, but scan not operational after that.
Only esp_restart() recover but we cannot use it since in our app we cannot loose BT radio more than 1 minute ( it not applicable for us to run esp_restart() every minute!!).
This is issue will kill our project....

TianaESP · 2021-06-15T07:31:55Z

@Rokachy Can you please try with the latest v4.3 release? We did a test and did not reproduce the issue. We are still testing with mass devices on the same.

Rokachy · 2021-06-15T08:33:32Z

Yes, I will and let you know for results.
Is a random issue, it can appear from few hours to few days....
Is there anything that I can read / get status from the device to help debug it?
Do you want me to open/enable other than logs?

Yehuda

TianaESP · 2021-06-15T08:56:34Z

@Rokachy Yes, it is a random issue. Am afraid no need to enable anything at the moment, the best would be packets capture. Please try with latest v4.3 first. Thanks.

Rokachy · 2021-06-22T06:22:17Z

Its runs with v4.3 release for a few days, no issue so far -:)
We will continue to run it for few days more.
What have been fixed at the SDK v4.3?

0neblock · 2021-06-28T06:13:43Z

@TianaESP Any chances of this (possible) fix being backported to v3.3?

TianaESP · 2021-06-28T11:43:25Z

@0neblock The fixes were backported to v3.3, v4.0, v4.1, v4.2. Please try the latest v3.3.
Thanks.

TianaESP · 2021-06-28T11:46:07Z

@Rokachy We fixed bugs in modem sleep that we suspected were contributing to the problem. Please let us know if the issue happens again. Thanks.

Rokachy · 2021-06-28T21:02:30Z

Thank you for the support, we are using release 4.3 and we didn't see the issue for the last 2 weeks. I hope it will be kept like this 😀. Thank you for the good work. Yehuda

…

On Mon, Jun 28, 2021, 14:46 TianaESP ***@***.***> wrote: @Rokachy <https://github.com/Rokachy> We fixed bugs in modem sleep that we suspected were contributing to the problem. Please let us know if the issue happens again. Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4001 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AS7K4PJZQ6Z4A7UH2VWTDPTTVBOIVANCNFSM4ITBESYQ> .

Rokachy · 2021-07-04T07:59:00Z

The fixes were backported to v3.3, v4.0, v4.1, v4.2. Please try the latest v3.3.

is the fix backported to 4.0.3 version too?

Alvin1Zhang · 2021-07-05T02:50:32Z

Thanks for sharing updates, the fix has already backported to release/4.0 b89b1ec, thanks.

MartinTJDK · 2021-07-06T12:28:14Z

I have observed an issue, which might relate to this. At least the result is the same: BLE stack stops to work properly...

In my situation, I am scanning for BLE advertisements, and at some point in time, the scan stops. It typically happens when ESP32 is busy (e.g. writing a lot of information to Debug Console).

I enabled "CONFIG_BLE_HOST_QUEUE_CONGESTION_CHECK", which helps a lot, and actually shows, that BTU queue "often" has congestion.

But I also observed (easy to reproduce by changing "BT_QUEUE_CONGEST_SIZE" to 20 in file "bt_common.h"), that when congestion occurs, it actually locks the ble stack completely.
Sometimes it does not recover, and I believe it is caused by "hciH4T" task having higher priority - and a lot event to process.

If I allow "hciH4T", "btuT" and "BTC_TASK" tasks to use same priority, I do not see this lockup.
Perhaps someone from Espressif (@TianaESP) could confirm the issue?

juanaviladev · 2021-12-30T16:52:58Z

Hi! Any update about this? I noticed this same issue when using BLE + Classic (v4.4-beta1). Thanks!

edit: v4.3.1 is also affected

Rokachy · 2022-01-02T21:27:45Z

We are using 4.3.1 and we are not seeing the issue

…

On Thu, Dec 30, 2021, 18:53 Juan Ávila ***@***.***> wrote: Hi! Any update about this? I noticed this same issue when using BLE + Classic (v4.4-beta1). Thanks! — Reply to this email directly, view it on GitHub <#4001 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AS7K4PPKJ26AMQ5UEROFOM3UTSE7LANCNFSM4ITBESYQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

juanaviladev · 2022-01-07T10:48:34Z

We are using 4.3.1 and we are not seeing the issue

Are you using bluedroid (with BTDM mode)? With only ble scan I can't reproduce it

I'm doing name requests (read_remote_name) and at the same time a ble scan

Rokachy · 2022-01-07T11:39:27Z

We are using ble scan.

…

On Fri, Jan 7, 2022, 12:48 Juan Ávila ***@***.***> wrote: We are using 4.3.1 and we are not seeing the issue … <#m_6376715294096464826_> On Thu, Dec 30, 2021, 18:53 Juan Ávila *@*.*> wrote: Hi! Any update about this? I noticed this same issue when using BLE + Classic (v4.4-beta1). Thanks! — Reply to this email directly, view it on GitHub <#4001 (comment) <#4001 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS7K4PPKJ26AMQ5UEROFOM3UTSE7LANCNFSM4ITBESYQ <https://github.com/notifications/unsubscribe-auth/AS7K4PPKJ26AMQ5UEROFOM3UTSE7LANCNFSM4ITBESYQ> . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: @.*> Are you using bluedroid (with BTDM mode)? With only ble scan I can't reproduce it — Reply to this email directly, view it on GitHub <#4001 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AS7K4PI44ASQV3SNT4M75BTUU3AI7ANCNFSM4ITBESYQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

ktonder · 2022-01-19T08:26:18Z

Using the latest Arduino ESP32, v 2.0.2 that uses idf 4.4-alpha1 I also get the error "BT_HCI: command_timed_out hci layer timeout waiting for response to a command. opcode: 0x200c"

When this happens I also see that the application reconnects to WiFi as I have WiFi / BLE co-existence. BLE scanning for 1 second at the time, then a short break before I start scanning again.

juanaviladev · 2022-01-23T15:27:02Z

Using the latest Arduino ESP32, v 2.0.2 that uses idf 4.4-alpha1 I also get the error "BT_HCI: command_timed_out hci layer timeout waiting for response to a command. opcode: 0x200c"

When this happens I also see that the application reconnects to WiFi as I have WiFi / BLE co-existence. BLE scanning for 1 second at the time, then a short break before I start scanning again.

+1, although the changelog includes this bug fix, it hasn't been resolved in the latest version yet. Also, since the bluetooth controller code is not open source, it is not possible to do anything on our side...

HeFeng1947 · 2022-04-06T02:26:21Z

Unfortunately, I seem to have the same problem.
My idf version is v4.2 c327a00
I have enabled ble wifi coexistence.Bluetooth scans all the time and sends it to the cloud server over wifi.

juanaviladev · 2022-05-06T10:10:42Z

v4.4.1, has the same problem. BLE/Classic BT + Wifi still unusable in a prod environment.

Zimbu98 · 2022-09-21T21:24:20Z

I had the same problem for months and finally solved it by adjusting the scan interval and scan window. I think the default might be 100/99 which gives very little resources for the ESP to "take out the trash" and "wash the dishes" when you are running a continuous scan like I am.

I changed it to 800/750 and now suddenly the scanner runs and runs without crapping out. Amazing! You can use different numbers I assume, but just be sure to leave some gap between the two numbers so the scanner will take a break and allow the ESP to do some other housekeeping. (I am just speculating that the housekeeping issue is the root of the problem; it might also be that the scanner is overheating or overeating or over somethinging.)

FYI, I had the same problem with the ESP32-WROOM-32U and also with the ESP32-C3. Changing to 800/750 solved it for both of them.

pschlan · 2022-09-23T18:05:25Z

Are you sure it's really solving it and not just making it less likely? Until the root cause for this is analyzed and fixed, I can't really trust the ESP in a production device when it comes to BT.

freemansu · 2022-11-23T02:21:22Z

V4.4.3 has the same problem.

thorrak · 2023-03-06T14:19:08Z

v4.4.4 (via the latest Arduino framework) has the same problem.

My gap between the interval and window is quite wide as per the suggestion by @Zimbu98 - unfortunately this had no effect.

github-actions bot changed the title ~~BT Controller - Stops Scanning or responding after random amount of time~~ BT Controller - Stops Scanning or responding after random amount of time (IDFGH-1781) Sep 3, 2019

jimmo mentioned this issue Oct 14, 2019

NimBLE scan stops generating results, then crashes when resumed. (IDFGH-2001) #4196

Closed

0neblock closed this as completed Apr 15, 2020

0neblock reopened this Apr 15, 2020

MartinTJDK mentioned this issue Jul 7, 2021

Deadlock in BLE (BT?) message queues (IDFGH-5513) #7242

Open

juanaviladev mentioned this issue Jan 7, 2022

Receive "scan_evt timeout" on serial monitor espressif/arduino-esp32#5860

Open

thorrak mentioned this issue Mar 8, 2023

scan_evt timeout error after 5-6 hours of scanning with esp32 h2zero/NimBLE-Arduino#460

Open

lis0r mentioned this issue Jan 1, 2024

Add a second recovery path if BLE stack stops being able to receive adverts arendst/Tasmota#20365

Closed

6 tasks

BT Controller - Stops Scanning or responding after random amount of time (IDFGH-1781) #4001

BT Controller - Stops Scanning or responding after random amount of time (IDFGH-1781) #4001

Comments

0neblock commented Sep 3, 2019 • edited Loading

Brief

Problem Description

Coredump

Debug Log

sdkconfig

Scanning Configuration Used

Changes Attempted

Environment

0neblock commented Sep 8, 2019

0neblock commented Sep 20, 2019

gengyuchao commented Sep 24, 2019

0neblock commented Sep 25, 2019

gengyuchao commented Sep 25, 2019

0neblock commented Sep 25, 2019

0neblock commented Oct 29, 2019

0neblock commented Nov 19, 2019

Sushant-Espressif commented Nov 19, 2019

0neblock commented Nov 19, 2019

0neblock commented Dec 11, 2019

pschlang commented Jan 13, 2020 • edited Loading

plebed commented Feb 14, 2020

0neblock commented Jun 19, 2020

plebed commented Jun 22, 2020

GianlucaLoi commented Sep 16, 2020

Sushant-Espressif commented Sep 16, 2020

GianlucaLoi commented Sep 16, 2020

GianlucaLoi commented Sep 17, 2020 • edited Loading

chhajedji commented Oct 19, 2020

GianlucaLoi commented Oct 19, 2020

chhajedji commented Oct 20, 2020

GianlucaLoi commented Oct 20, 2020 • edited Loading

chhajedji commented Oct 20, 2020

GianlucaLoi commented Oct 22, 2020 • edited Loading

chhajedji commented Oct 22, 2020

chhajedji commented May 18, 2021

vbvchauthmal commented May 21, 2021

Rokachy commented Jun 10, 2021

TianaESP commented Jun 15, 2021

Rokachy commented Jun 15, 2021

TianaESP commented Jun 15, 2021

Rokachy commented Jun 22, 2021

0neblock commented Jun 28, 2021

TianaESP commented Jun 28, 2021

TianaESP commented Jun 28, 2021

Rokachy commented Jun 28, 2021 via email

Rokachy commented Jul 4, 2021

Alvin1Zhang commented Jul 5, 2021

MartinTJDK commented Jul 6, 2021 • edited Loading

juanaviladev commented Dec 30, 2021 • edited Loading

Rokachy commented Jan 2, 2022 via email

juanaviladev commented Jan 7, 2022 • edited Loading

Rokachy commented Jan 7, 2022 via email

ktonder commented Jan 19, 2022

juanaviladev commented Jan 23, 2022

HeFeng1947 commented Apr 6, 2022 • edited Loading

juanaviladev commented May 6, 2022 • edited Loading

Zimbu98 commented Sep 21, 2022

pschlan commented Sep 23, 2022

freemansu commented Nov 23, 2022

thorrak commented Mar 6, 2023

0neblock commented Sep 3, 2019 •

edited

Loading

pschlang commented Jan 13, 2020 •

edited

Loading

GianlucaLoi commented Sep 17, 2020 •

edited

Loading

GianlucaLoi commented Oct 20, 2020 •

edited

Loading

GianlucaLoi commented Oct 22, 2020 •

edited

Loading

MartinTJDK commented Jul 6, 2021 •

edited

Loading

juanaviladev commented Dec 30, 2021 •

edited

Loading

juanaviladev commented Jan 7, 2022 •

edited

Loading

HeFeng1947 commented Apr 6, 2022 •

edited

Loading

juanaviladev commented May 6, 2022 •

edited

Loading