ASSERT_PARAM(4 13), in llm_util.c at line 215 (IDFGH-6912) #8532
Comments
github-actions
bot
changed the title
|
With esp-idf 4.3.2, the crash happened on all units from within an hour to a few. After reverting back to esp-idf to 4.3.1, no crash was observed on 5 units that had been running over 20 hours. |
@chewhs00 |
|
@AxelLin , after going thru "git bisect", this is what I found: commit 2e74914 (HEAD, tag: v4.3.1) GOOD HEAD detached at v4.3.1-240-ga05d4e9e86 GOOD HEAD detached at v4.3.1-360-gb6806002df BAD HEAD detached at v4.3.1-300-g43d2a6eeed GOOD HEAD detached at v4.3.1-330-g44c701abb6 BAD HEAD detached at v4.3.1-314-ge4995581dc GOOD HEAD detached at v4.3.1-322-gdfe5f7432f BAD HEAD detached at v4.3.1-318-gb5936c8323 GOOD HEAD detached at v4.3.1-320-g717627ad1a GOOD HEAD detached at v4.3.1-303-g521c0ef956 GOOD dfe5f74 is the first bad commit components/bt/controller/lib_esp32 | 2 +- |
|
With ESP-IDF commit dfe5f74, ASSERT_PARAM(4 13), in llm_util.c at line 215 Core 0 register dump: Backtrace:0x40084d5c:0x3ffea0f0 0x40085112:0x3ffea110 0x40141901:0x3ffea130 0x4013e9bb:0x3ffea180 0x4013bc4e:0x3ffea1d0 0x40019d11:0x3ffea210 0x40055b4d:0x3ffea230 0x40132a57:0x3ffea250 0x4013309c:0x3ffea270 0x40084d5c: r_assert at ??:? |
|
@chewhs00 I have had the same issue today: As far as I can tell, the ESP32 reboots every time, but any connection is lost. Please let me know if anybody finds a fix for this. Our client is waiting for a solid firmware to release and this issue is not acceptable. I am also using the 4.3.2 library and am connected to AWS MQTT on Wifi with bluetooth devices simultaneously connected to the ESP32. |
|
Just noticed 4.3.3 has been released. Any update if this issue has been taken care of? |
|
Hi mbisso64, Have you tried on IDF4.3.3? Could you please give us the ELF file to generate the backtrace ? Thanks, |
|
Using IDF v4.4.1 and I regularly get this issue. Moreover after core reset there is some error because my esp cannot get ip. I do reset by pushing reset button and everythnig works back again. |
|
Hi @MrHause, |
|
Sure, my code is more advanced right now. But I started with gatc_multi_connect example. I use ESP32-POE-ISO by OLIMEX. |
|
Hi @MrHause , |
|
Hi @MrHause , I'm trying to reproduce the issue but have not yet hit it, Meanwhile could you please attach the ELF file and core dump here so that I can backtrack and find the root cause of it . Thanks, |
|
I know that controller should disallow another scan command but I'm not saying that start_scan() function caused the problem but rather the place where this function in example is called. In my system, the esp32 is connected with 4 Nordic devices. I started getting this issue when the devices started performing more communication. Unitl the device were exchanging less data everything was ok. I google for error that I get and found this site: When I figurred out that this issue is connected with scanning I checked my soft and I found that on each received message I start scanning. What is completely useless. I moved start_scan() function to other event and so far I didn't get this error. I can't give you right now the core dump because I didn't save it and it's not so easy to setup whole environment and reset code to reproduce this issue. I gave you the steps. I have to say that I made a lot of changes in comparison to orignal example. I left only the connection procedure. The code presented in this example is not good and optimal. Maybe my changes have affected on it. The same day when I got this issue I solved it so I can't even say how often it was happening. |
|
Hi, @MrHause, I Have gone through the code and assert it looks like in the connection state we have received the REJ_IND_PDU cause the assert. We were not expecting REJ_IND_PDU in the connection state from the peer device, Once you have hit this assertion we need to find out which PDU of ESP32 peer has sent REJ IND PDU and the root cause of it. Thanks, |
|
May be related to the fix #6800 |
|
Trying to follow up if there is a fix on this which I do not have this issue with idf 4.3.1. Same issue occurs on v4.4.4 |
|
Does the issue still exist in the latest version? |
Last I checked the issue still exists with idf 4.4.4. I didn't get a chance to try it on 5.1.1 since there are a lot of code compatibility issues that require some changes on our codes. |
|
I use idf stable(5.1.2), and still see this issue. In this project, ble and wifi(websocket client) are uesd at the same time. �[0;32mI (109550) WIFI_MSG: heap remain: 877099�[0m Backtrace: 0x40086f6c:0x3ffd2ba0 0x4008722b:0x3ffd2bc0 0x40111ca9:0x3ffd2be0 0x4010ea27:0x3ffd2c30 0x4010b9de:0x3ffd2c80 0x40019d11:0x3ffd2cc0 0x40055b4d:0x3ffd2ce0 0x400ffecb:0x3ffd2d00 0x40100542:0x3ffd2d20 0x40097f86:0x3ffd2d50 |
|
Hi JD-SX, |
|
@JD-SX |
The role of esp32 is ble central I install the idf from the link in espressif website: I will ask my boss to see if I can share the elf file. |
|
Hi JD-SX |
Thank you, I will test it and check the result. |
I tested with the libbtdm.a for several hours, and got the same error. �[0;32mI (59320) PTO: QQQ: 0 0.076�[0m Backtrace: 0x40086f6c:0x3ffd3350 0x4008722b:0x3ffd3370 0x40111c7d:0x3ffd3390 0x4010e9fb:0x3ffd33e0 0x4010b9b2:0x3ffd3430 0x40019d11:0x3ffd3470 0x40055b4d:0x3ffd3490 0x400ffe9f:0x3ffd34b0 0x40100516:0x3ffd34d0 0x40097f86:0x3ffd3500 The decoded result is: |
|
I do a fullclean and test again, and see some reset due to "coex_bt_callback at arch_main.c" I (382270) NimBLE: GATT procedure initiated: write; send start...done: 13 ms, 497 bytes ASSERT_PARAM(4 9), in llm_util.c at line 215 Core 0 register dump: A2 : 0x00000000 A3 : 0x00000004 A4 : 0x00000009 A5 : 0x3f4f0be1 0x40095a2d: strcmp at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/strcmp.S:544 Backtrace: 0x40086f6c:0x3ffd3340 0x4008722b:0x3ffd3360 0x401115a1:0x3ffd3380 0x4010e2e3:0x3ffd33d0 0x4010b29a:0x3ffd3420 0x40019d11:0x3ffd3460 0x40055b4d:0x3ffd3480 0x400ffc83:0x3ffd34a0 0x401002fa:0x3ffd34c0 0x40097f86:0x3ffd34f0 0x4008722b: r_assert_param at ??:? 0x401115a1: r_llm_pdu_defer at ??:? 0x4010e2e3: r_lld_pdu_check at ??:? 0x4010b29a: r_lld_evt_deffered_elt_handler at ??:? 0x40019d11: r_ke_event_schedule in ROM 0x40055b4d: r_rwip_schedule in ROM 0x400ffc83: r_rw_schedule at ??:? 0x401002fa: btdm_controller_task at ??:? 0x40097f86: vPortTaskWrapper at C:/Users/jdhua/.espressif/frameworks/esp-idf-v5.1.2/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162 |
|
@JD-SX |
|
@JD-SX |
|
@JD-SX I (31) boot: ESP-IDF v5.1.2-691-g7380f96017-dirty 2nd stage bootloader I (0) cpu_start: App cpu up. |
Thank you. |
|
When applying the new library(6697dfa), encountered the following issue during link stage: [1364/1366] Linking CXX executable sta_fw_neo.elfFAILED: sta_fw_neo.elf ========================================================= Using 'git log' to check the latest commit, the result is as follows: PS C:\Users\jdhua.espressif\frameworks\esp-idf-v5.1.2> git log -p -2 diff --git a/components/esp_common/include/esp_idf_version.h b/components/esp_common/include/esp_idf_version.h /**
set(ENV{IDF_VERSION} "${IDF_VERSION_MAJOR}.${IDF_VERSION_MINOR}.${IDF_VERSION_PATCH}") commit 9f2a2db |
|
idf_py_stdout_output_1388.zip I used a specific version of IDF(7380f96), along with a specified library(6697dfa). After running for ten hours, there was one reset, but it was unrelated to Bluetooth. I believe the issue has been resolved. Thank you. |
|
@JD-SX |
Esp32 connects to 2~4 nrf52840 with notification enable, and also connect to remote server by websocket. Esp32 polls each nrf42840 for data retrieving each second, and send data to server. The ble & wifi coexist issue is solved by adopted the library(6697dfa). The new issue is rising when destorying websocket; might be stack overflow. websocket client keeps connection with server and send data to server. ble central collects data from each nrf52840. I configured the wifi task with a larger stack (8192 bytes) two hours ago; so far so good. |
espressif-bot
added
Status: Done
|
Closing the issue as solved, if you will encounter any more issues feel free to reopen this or create a new issue. Cheers! |
Environment
Development Kit: None
Module or chip used: ESP32-WROVER-E (16MB)
IDF version (run git describe --tags to find it): v4.3.2
Build System: idf.py
Compiler version (run xtensa-esp32-elf-gcc --version to find it): xtensa-esp32-elf-gcc (crosstool-NG esp-2021r2) 8.4.0
Operating System: Guest OS Ubuntu on Windows
Using an IDE?: No
Power Supply: 3.7V Lithium
Problem Description
The custom board has a connection to AWS IoT MQTT service, a BLE connection a custom app listening to the notification, and a task performing 5-sec windows Bluetooth scanning for non-connectable peripherals at every 5 seconds interval. The crash can be any point in time within hour to sometimes several hours. I have searched the web but could not find anything about the above ASSERT. Not sure if it is related to this issue: #8448
Debugging Logs
ASSERT_PARAM(4 13), in llm_util.c at line 215
Guru Meditation Error: Core 0 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x400843f8: 0000f01d 00004136 f01d0000
Core 0 register dump:
PC : 0x400843ff PS : 0x00060730 A0 : 0x800847b5 A1 : 0x3ffe93e0
A2 : 0x00000000 A3 : 0x00000004 A4 : 0x0000000d A5 : 0x3f580972
A6 : 0x000000d7 A7 : 0xfffffffc A8 : 0x8000814b A9 : 0x3ffe9350
A10 : 0x00000000 A11 : 0x3ffe9373 A12 : 0x3ffe931f A13 : 0x00000035
A14 : 0x00000000 A15 : 0x3ffe9324 SAR : 0x00000004 EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000 LBEG : 0x400846bd LEND : 0x400846c5 LCOUNT : 0x00000000
Backtrace:0x400843fc:0x3ffe93e0 0x400847b2:0x3ffe9400 0x401408a1:0x3ffe9420 0x4013d95b:0x3ffe9470 0x4013abee:0x3ffe94c0 0x40019d11:0x3ffe9500 0x40055b4d:0x3ffe9520 0x401311a3:0x3ffe9540 0x40131824:0x3ffe9560
The text was updated successfully, but these errors were encountered: