Crash after Nimble initialisation on ESP-IDFv.5.0.1, works on v.5.0 (IDFGH-9450) #10817
Closed
3 tasks done
Labels
Resolution: Done
Issue is done internally
Status: Done
Issue is done internally
Type: Bug
bugs in IDF
Comments
github-actions
bot
changed the title
|
Hi @jacek12345, |
|
Hi @jacek12345 , any updates ? |
|
Now tried with ESP-IDF-v.5.1-rc1 and still have a problem. I made "fullclean" and "set-target esp32-s3". After that, th eoutput was little different, but next run was the same as above. What is the best way for installing new ESP-IDF? I dont't know how to make shortcut for starting ESP-IDF. When i installed a lot of time ago my 4.4.3 version it created "ESP-IDF v4.4.3" shortcut. Now it doesn't create. |
|
Hi @jacek12345 , To enable debug logs:
|
|
I'm trying to run with enabled debug logs but have: |
|
Hey, |
|
Thank You @AxelLin and @IshaESP Is it enough or You meed whole log? I'm aware that there can be some secret information. Eventually can send priv? |
|
@IshaESP This is not switch example. This is only based on switch example project. |
|
I made one more time install.bat and export.bat in v5.1-rc1, and here is log Attached also sdkconfig |
|
Do You have any idea? Or any example with reusing NimBle after provisioning? |
|
Hey @jacek12345 , Looking at your log, we see that you have somehow by passed the internal nimble initialization which happens via the wifi_provisioning -- protocomm layer endpoint. Since there appears to be code changes, is it possible for you to suggest any way to use IDF examples to reproduce the issue you have mentioned ? Any minimalistic change we can do to simulate the same scenario as seen at your end. We would have performed git bisect to find failing commit, but we can do it once we are able to reproduce the issue at our end |
|
I just updated ESP-IDF to 5.1 release. Still have a problem.
On the beginning: On the end: Zipped 'main' folder from Rainmaker 'switch' example. |
|
Hi @jacek12345, The patch shared above has API's name as bleprph but the code is actually performing blecent role of scanning. The solution to this is:
|
|
@IshaESP , Proposed solution works only when device is unprovisioned and then go throw provisioning process. After restart, when device is already provisioned it doesn't work.
Why it prevents BT stack initialising? If BT is deinitialised after provisioning, it should be abble to initialise it one more time. Isn't it? I think that the only way is to disable WIFI_PROV_KEEP_BLE_ON_AFTER_PROV and initialise BLE always from the beginning I also tried to add only nimble_port_stop(); and there is crasch immediately. |
|
Hi @jacek12345, This is the documentation . The current use supported is to use BLE stack for provisioning and then turn off stack and release memory . Therefore , memory too is released . But when memory is released, it cannot be reversed. |
|
Thank You for response.
But if i understood, now, when device is already provisioned it should work with my own BT initilaisation regardless of WIFI_PROV_KEEP_BLE_ON_AFTER_PROV, but it crasches. Why? From the nimble/blecent example: In my case, it crashes on So I suppose that there is also other issue with it. Is it possible that i don't have some submodules installed or wrong version ? |
|
Hi @jacek12345 , Here are the 2 cases that need to be addressed:
|
|
I have |
|
Finally, it looks like the problem was missing: But there is strange issue with WIFI_PROV_KEEP_BLE_ON_AFTER_PROV. If disabled, it crashes on ble initialisation even if there was not provisioning in this boot (ble was not already initialised). If enabled, initialisation take place correctly. This is strange, because it shouldn't be used when there was not provisioning in this boot. |
|
Hi So if provisioning is already done, you need to enable WIFI_PROV_KEEP_BLE_ON_AFTER_PROV for using BLE. During init process, if the flag is disabled, it releases all the memory related to ble thus causing a crash (irrespective of provisioning). Attaching a log when WIFI_PROV_KEEP_BLE_ON_AFTER_PROV is enabled and provisioning is already done. |
|
Hi @jacek12345 , any further updates regarding WIFI_PROV_KEEP_BLE_ON_AFTER_PROV macro usage ? |
|
I ran into the same issue working on an esp-matter based project, which is running on tag v5.1.1. It occurs while booting a commissioned device (this should be the normal state). And let me tell it is very urgent. I looked around in the files and was thinking about why there is no sanity-check if the element in the linked list actually has a next element. The next element will just be used... I really don't know if there are some specialties on this linked list (like being a closed loop), but anyhow, it is just a guess... Even if it should not appear in reality, there should be a check for Here is my stack trace: EDIT: I guess I guessed wrong, but still, the error is there... so is it some memory corruption? |
Thank You, I have this enabled and everything works. You can close. |
|
I would say, the flag may ease the symptom by the root is somewhere else. As I wrote, the Matter implementation from Espressif also uses the Nimble-Stack, at completely controls it. So no interaction by my application code. And it still appears. Should I guide someone from the esp-matter repo here? |
|
Hi @PhLuReh , i believe the issue you have raised and the one being discussed on this ticket are not same. I suggest to please open a fresh ticket on esp-matter repo. Also request you :
I will be closing the current issue. |
espressif-bot
added
Resolution: Done
|
@rahult-github I will do so. Just to conclude from my side. I added the following line to the list.c code and the abort get's executed: So I would assume, pxItemToRemove get's corrupted, is not NULL but according to the BT |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Answers checklist.
IDF version.
esp-idf-v5.0.1
Operating System used.
Windows
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
CMD
Development Kit.
ESP32-S3-DevKitM-1
Power Supply used.
USB
What is the expected behavior?
Nimble initialisation
What is the actual behavior?
Crash
Steps to reproduce.
Used with RainMaker based project.
Nimble_init();it crashes.Debug Logs.
More Information.
It seems that BT controller version is the problem?
When crashing (ESP-IDFv.5.0.1):
I (34710) BT_INIT: BT controller compile version [80abacd]
When works (ESP-IDFv.5.0):
I (25431) BT_INIT: BT controller compile version [76c24c9]
The text was updated successfully, but these errors were encountered: