-
Notifications
You must be signed in to change notification settings - Fork 7.4k
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
ASSERT_PARAM(196608 0), in rwbt.c at line 381 (IDFGH-6777) #8405
Comments
@MikitaMinau Please update to the latest IDF master and try. Please let me know if you have the same issue |
@Weijian-Espressif Thank you for your reply.
Thanks. |
We fix the bug about |
@Weijian-Espressif We cannot use unstable master branch for production. |
Which commit fixed this issue in master? |
Please help test whether the latest master still has the problem you feedback, just for testing |
@Weijian-Espressif I understand you point but this bug is difficult to reproduce, it does not happen often. |
@Weijian-Espressif |
It seems the bug is still present on 4.4.1. I personally cannot reproduce it on my board, but one of our users complained about it. It seems to trigger sporadically, even without a connected BLE device. Strangely the assert looks a bit different:
|
I tried digging deeper, so I monitored my Serial output using IDF Tools and now got this stacktrace on latest release/v4.4 branch (c5deb7a):
@Weijian-Espressif Any idea what is going on there? |
@Weijian-Espressif
|
Hi @bbsan2k , Thanks, |
Hi @SatishSolankeEsp , Is this of any help? If required I can send you a version of our App, but as the issue is so hard to reproduce it may take up to 5 hours until it finally triggers. |
Any update on this @SatishSolankeEsp |
IDF ver: 4.4.2 (used by arduino core 2.0.5) In my project, I use a devboard esp32-wroom-32, running a telegram-bot, and a task that is constantly trying to connect to a device via bluetooth spp, in order to then receive and process data from it. Recently, while trying to connect with a turned off device, I caught this error:
|
I'm also running into this with a Bluetooth classic audio application that is connected to a WiFi station and has an open TCP connection for remote DSP control. The TCP connection is not actively doing anything at the time this occurs, so WiFi is mostly idle, aside from whatever it needs to do to maintain the connection. There are times when the application will run like this all day long without a problem, and times when the application will crash within 10 minutes of boot.
Bluetooth modem sleep is disabled. High level interrupt is disabled.
It would be great if you could release the source code to these files so that these backtraces are more helpful and so I could dig |
The Arduino team can't help too much on this issue given it seems related to IDF. |
I built my project with
Maybe this will help... |
How long do you think it takes approximately to wait, and is anyone dealing with this problem right now? |
This issue still persists with ESP-IDF v5.1 (with esp-adf freertos patch, ESP-ADF version 2.6) I cannot try a newer IDF version, as 5.1 is the latest one supported by ADF v2.6, the latest ADF version. I cannot upgrade to master at the time being. ESP32-WROVER-E on a custom board which is a copy of LyraT v4.3
|
Hi, @noqnio
|
@ESP-YTGerd How about the fix for v5.2 branch? |
Fix for branch release/v5.2 has not been merged internally. I will update this as soon as it gets merged. |
It seems fixed for me on release/v5.1 |
Hi, @AxelLin |
@ESP-YTGerd This should be closed. |
Thanks for reporting, we will close this issue. Feel free to reopen if have more updates. |
Environment
Problem Description
Assert in rwbt.c was called after a client connected to BLE.
Before that lld_pdu_get_tx_flush_nb HCI packet count mismatch (2, 1) error happened followed by disconnection event.
Automatic light sleep and dynamic frequency scaling were enabled.
BLE was scan was disabled.
Expected Behavior
BLE works stable.
Actual Behavior
Assert was called in rwbt.c.
Steps to reproduce
No specific steps.
Assert happened shortly after a client connected to ESP32 over BLE.
Code to reproduce this issue
Unfortunately, I am not able to share project code.
Debug Logs
Other items if possible
sdkconfig.txt
The text was updated successfully, but these errors were encountered: