Skip to content
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

scan_evt timeout error after 5-6 hours of scanning with esp32 #460

Open
berkayozcan opened this issue Oct 11, 2022 · 14 comments
Open

scan_evt timeout error after 5-6 hours of scanning with esp32 #460

berkayozcan opened this issue Oct 11, 2022 · 14 comments

Comments

@berkayozcan
Copy link

berkayozcan commented Oct 11, 2022

ESP32 got stuck after 5-6 hours of scanning with "scan_evt timeout" error. nimBLE version 1.4.0

@h2zero
Copy link
Owner

h2zero commented Oct 11, 2022

This is an issue with esp-idf BT controller. Will need to wait for an update from espressif.

espressif/esp-idf#9384

@h2zero
Copy link
Owner

h2zero commented Nov 6, 2022

Ran into this issue yesterday with arduino-esp32 core version 2.0.5. Only seems to be triggered randomly when using BLE and WiFi. Downgrading to 2.0.4 seems to resolve the issue for now.

@Bascy
Copy link
Contributor

Bascy commented Nov 25, 2022

Might this have to do with running out of memory when using indefinity scan because m_scanResults.m_advertisedDevicesVector and duplicatesCache keeps growing?

I have posted a pull request to fix this: #480

You also need to set maxResults to something < 0xFF when using scanDuration == 0

@h2zero
Copy link
Owner

h2zero commented Nov 25, 2022

I don't believe this to be the cause, but worth testing. The duplicate cache clears itself (or at least it's supposed to) when it reaches the number of devices set by setScanDuplicateCacheSize.

@Bascy
Copy link
Contributor

Bascy commented Nov 25, 2022

We are using a scan with a scanDuration == 0 and see a steady decline in available memory.
We thought we had solved it by setting maxResults == 0 and regularly clearing the duplicates cache (we re not using duplicate filtering) but that doesn't seem to work

@Bascy
Copy link
Contributor

Bascy commented Nov 25, 2022

It turns out that i'm getting a lot of advertisements (of for me unknown devices) which are added to the scanResult m_advertisedDevicesVector but for which the callback method is never called, and hence they are never removed from the vector.

To test this I added some code to periodically remove all advertisements in the vector that are older than 10 sec, and now my memory use is stable.

I can't find any documentation on the event_type's that are used in if statements in NimBKEScan.cpp

Running scans in passive mode solved the problem!

@thorrak
Copy link
Contributor

thorrak commented Mar 8, 2023

Unfortunately, I've been running into this problem recently, and through trial and error can confirm that this doesn't seem to work on either Arduino v2.0.7 or v2.0.4-- though v2.0.4 seemed to last an average of 4 hours before becoming unresponsive while v2.0.7 only seemed to last an average of 2 hours before things became an issue.

Changing the scan time, windows, etc. doesn't seem to help, but passive scanning does seem to resolve the issue.

The issue has been raised a number of times over the years with Espressif -- both in arduino-esp32 and esp-idf:

...however the only good news in any of those issues is that the issue is supposedly resolved in the v5.x line of esp-idf which will one day become the v3.x line of the Arduino framework.

That said -- sounds like this error is potentially going to be solved in the next few months. Fingers crossed!

@Ritesh236
Copy link

Hello,

We are also facing issues randomly like after 15 to 20 days like evt_scan timeout prints are coming continuously. We are using ESP32 IDF 5.1 Release and Wi-Fi and BLE together.

So, Would you please help me like what can be the cause for the same?

Let me know if need anything else from my end.

Regards,
Ritesh Prajapati

@h2zero
Copy link
Owner

h2zero commented Sep 24, 2023

As mentioned above there is nothing we can do here as this is a problem with the controller and needs to be resolved by espressif.

@Ritesh236
Copy link

As mentioned above there is nothing we can do here as this is a problem with the controller and needs to be resolved by espressif.

Hello,

Understood but issue I am facing randomly like there is no any fixed pattern to reproduce this issue. Espressif Team has also provided few debug library for BT perspective but still not able to reproduce issue again.

I believe issue into scanning process handling perspective while issue is reproduced.

Regards,
Ritesh Prajapati

@Reneslasertag
Copy link

I see the message "scan_evt timeout" in my terminal, but I did not find the file with the function where it prints this. Where can I find it? If I got a handler (or something) that is called when this error occurs, I could use it to just restart the device...

@Ritesh236
Copy link

I see the message "scan_evt timeout" in my terminal, but I did not find the file with the function where it prints this. Where can I find it? If I got a handler (or something) that is called when this error occurs, I could use it to just restart the device...

Hello @Reneslasertag ,

Please find below link which I have already raised issue earlier over ESP32 community as well.

https://esp32.com/viewtopic.php?f=13&t=35396

I believe those prints are coming from BT Stack Library for which code is not open. But, as per discussion with team that they have already fixed into newer IDF but still need to confirm with them with commit ID if already patch is applied from their end.

Regards,
Ritesh Prajapati

@h2zero
Copy link
Owner

h2zero commented Jan 27, 2024

This has been fixed in IDF, not yet in Arduino releases as far as I know.

@Ritesh236
Copy link

This has been fixed in IDF, not yet in Arduino releases as far as I know.

@h2zero , Thanks for providing updates from your end.

Regards,
Ritesh Prajapati

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants