ASSERT_PARAM(4 13), in llm_util.c at line 215 (IDFGH-6912)

[chewhs00]

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: https://github.com/espressif/esp-idf/issues/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

[chewhs00]

With esp-idf 4.3.2, the crash happened on all units from within an hour to a few. The crash happens during a periodic call of esp_ble_gap_start_scanning(5), right after the gap event ESP_GAP_BLE_SCAN_START_COMPLETE_EVT.

After reverting back to esp-idf to 4.3.1, no crash was observed on 5 units that had been running over 20 hours.

[AxelLin]

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 Can you use "git bisect" to figure out the first bad commit? Also please decode the backtrace.

[chewhs00]

@AxelLin , after going thru "git bisect", this is what I found:

commit 2e74914051d14ec2290fc751a8486fb51d73a31e (HEAD, tag: v4.3.1) GOOD commit 8bf14a9238329954c7c5062eeeda569529aedf75 (HEAD, tag: v4.3.2) BAD

HEAD detached at v4.3.1-240-ga05d4e9e86 GOOD Submodule path 'components/bt/controller/lib_esp32': checked out 'cfbb0571fb424ca4a68a0c172cbff1fdc79fd91b' Submodule path 'components/bt/controller/lib_esp32c3_family': checked out 'a8099f0c7f1976c3a6ccd44a106728c87a78b1aa' Submodule path 'components/bt/host/nimble/nimble': checked out 'aef55bbf636ed580d4d6408a5c2e75d1f70a875e' Submodule path 'components/esp_wifi/lib': checked out 'e6945e61f7c63545a77b0575c3770a85b4de948e' Submodule path 'components/esptool_py/esptool': checked out '258301731780493365bb249553ae7855a3e753ea' Submodule path 'components/expat/expat': checked out 'a28238bdeebc087071777001245df1876a11f5ee' Submodule path 'components/lwip/lwip': checked out '2195f7416fb3136831babf3e96c027a73075bd4f' Submodule path 'components/mbedtls/mbedtls': checked out '6465247f67167518b8813ae2faaf422704e4b1a3' Submodule path 'components/mqtt/esp-mqtt': checked out 'f10321a53b53a146ee299cfecc320b89c0cf6611'

HEAD detached at v4.3.1-360-gb6806002df BAD Submodule path 'components/bt/controller/lib_esp32': checked out '1c6d248b6296473a353047700922534b09d9203f' Submodule path 'components/bt/host/nimble/nimble': checked out '6a06e0459e43771066160f5cfade55bb749fbacd' Submodule path 'components/esp_wifi/lib': checked out '52cb084bd5469659934dde8a8733106fe75824ac'

HEAD detached at v4.3.1-300-g43d2a6eeed GOOD Submodule path 'components/bt/controller/lib_esp32': checked out 'cfbb0571fb424ca4a68a0c172cbff1fdc79fd91b' Submodule path 'components/esp_wifi/lib': checked out '3cc2b74980f1768ef68dd85e5d9f6ecf94a594ba'

HEAD detached at v4.3.1-330-g44c701abb6 BAD Submodule path 'components/bt/controller/lib_esp32': checked out '3c91a5b84b9710d77e7f9dd27be461c92edfc805'

HEAD detached at v4.3.1-314-ge4995581dc GOOD Submodule path 'components/bt/controller/lib_esp32': checked out 'cfbb0571fb424ca4a68a0c172cbff1fdc79fd91b'

HEAD detached at v4.3.1-322-gdfe5f7432f BAD Submodule path 'components/bt/controller/lib_esp32': checked out '3c91a5b84b9710d77e7f9dd27be461c92edfc805'

HEAD detached at v4.3.1-318-gb5936c8323 GOOD Submodule path 'components/bt/controller/lib_esp32': checked out 'cfbb0571fb424ca4a68a0c172cbff1fdc79fd91b'

HEAD detached at v4.3.1-320-g717627ad1a GOOD

HEAD detached at v4.3.1-303-g521c0ef956 GOOD Submodule path 'components/bt/controller/lib_esp32': checked out '3c91a5b84b9710d77e7f9dd27be461c92edfc805'

dfe5f7432fbd15e20a7360ac5167b808690b6f9e is the first bad commit commit dfe5f7432fbd15e20a7360ac5167b808690b6f9e Merge: 717627ad1a 521c0ef956 Author: Wang Meng Yang wangmengyang@espressif.com Date: Mon Oct 25 07:53:16 2021 +0000

Merge branch 'bugfix/fix_ble_scan_failed_issue_master_4.3' into 'release/v4.3'

Fix the ble scan failed issue

See merge request espressif/esp-idf!15588

components/bt/controller/lib_esp32 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[AxelLin]

Add @xiongweichao @xiewenxiang @BetterJincheng

[chewhs00]

With ESP-IDF commit dfe5f7432fbd15e20a7360ac5167b808690b6f9e,

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 0x40084d58: 0000f01d 00004136 f01d0000

Core 0 register dump: PC : 0x40084d5f PS : 0x00060030 A0 : 0x80085115 A1 : 0x3ffea0f0
A2 : 0x00000000 A3 : 0x00000004 A4 : 0x0000000d A5 : 0x3f58796a
A6 : 0x000000d7 A7 : 0xfffffffc A8 : 0x8000814b A9 : 0x3ffea060
A10 : 0x00000000 A11 : 0x3ffea083 A12 : 0x80084bf8 A13 : 0x3ffbece0
A14 : 0x00000000 A15 : 0x3ffea034 SAR : 0x00000004 EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000 LBEG : 0x4008501d LEND : 0x40085025 LCOUNT : 0x00000000

Backtrace:0x40084d5c:0x3ffea0f0 0x40085112:0x3ffea110 0x40141901:0x3ffea130 0x4013e9bb:0x3ffea180 0x4013bc4e:0x3ffea1d0 0x40019d11:0x3ffea210 0x40055b4d:0x3ffea230 0x40132a57:0x3ffea250 0x4013309c:0x3ffea270

0x40084d5c: r_assert at ??:? 0x40085112: r_assert_param at ??:? 0x40141901: r_llm_pdu_defer at ??:? 0x4013e9bb: r_lld_pdu_check at ??:? 0x4013bc4e: r_lld_evt_deffered_elt_handler at ??:? 0x40019d11: ?? ??:0 0x40055b4d: ?? ??:0 0x40132a57: r_rw_schedule at ??:? 0x4013309c: btdm_controller_task at ??:?

[mbisso64]

@chewhs00 I have had the same issue today:

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 0x4008a914: 0000f01d 00004136 f01d0000
Core  0 register dump:
PC      : 0x4008a91b  PS      : 0x00060730  A0      : 0x8008acd1  A1      : 0x3ffb5a60
A2      : 0x00000000  A3      : 0x00000004  A4      : 0x0000000d  A5      : 0x3f42967e
A6      : 0x000000d7  A7      : 0xfffffffc  A8      : 0x8000814b  A9      : 0x3ffb59d0
A10     : 0x00000000  A11     : 0x3ffb59f3  A12     : 0x3ffb599f  A13     : 0x00000035
A14     : 0x00000000  A15     : 0x3ffb59a4  SAR     : 0x00000004  EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000  LBEG    : 0x4008abd9  LEND    : 0x4008abe1  LCOUNT  : 0x00000000

Backtrace:0x4008a918:0x3ffb5a60 0x4008acce:0x3ffb5a80 0x401a0769:0x3ffb5aa0 0x4019d7f3:0x3ffb5af0 0x4019aa82:0x3ffb5b40 0x40019d11:0x3ffb5b80 0x40055b4d:0x3ffb5ba0 0x4019102f:0x3ffb5bc0 0x401916a8:0x3ffb5be0 0x4009997d:0x3ffb5c10

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.

[chewhs00]

Just noticed 4.3.3 has been released. Any update if this issue has been taken care of?

[SatishSolankeEsp]

Hi mbisso64,

Have you tried on IDF4.3.3? Could you please give us the ELF file to generate the backtrace ? Could you please let us know which Host are you using? Give more info about the assert, it will help to reproduce the issue.

Thanks, Satish

[MrHause]

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. In my case the reason was starting scanning on each publish event. That mistake comes from ble example for multiple connection. So starting scanning too often caused this issue.

[SatishSolankeEsp]

Hi @MrHause, Could you please tell us the steps to reproduce the issue/example your running? Thanks, Satish

[MrHause]

Sure, my code is more advanced right now. But I started with gatc_multi_connect example. I use ESP32-POE-ISO by OLIMEX. In this example someone put start_scan() function in ESP_GATTC_WRITE_CHAR_EVT. It was ok because it allowed to connect to multiple devices. But whenerver I was sending ble msg I got this event and the start scanning function was called. So when I was sending a lot of ble data the scanning procedure were started too often. After a while it was causing described error and core was reset. I'm using ethernet and mqtt protocol also. After reset esp cannot get ip address. I solved this by moving the start_scan() function from ESP_GATTC_WRITE_CHAR_EVT to other event what allows scannig for multiple devices but scanning is now not started when I send messages. Hope I explained it clearly. Someone put start_scan() function in wrong event to allow scanning for multiple devices. Originally it worked as follow: When esp connected to DEVICE_1 and got ESP_GATTC_WRITE_CHAR_EVT event it was starting scannig for DEVICE_2 and so on. But the consequence was that scanning procedure was starting after every send message also.

[SatishSolankeEsp]

Hi @MrHause , Thank You for the steps will try to reproduce the issue and get back to you .....!!! Regards, Satish

[SatishSolankeEsp]

Hi @MrHause , I have gone through the code looks like the start_scan() function is not the issue Host can start the scan at any point if scanning has already progressed controller will disallow the command.

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, Satish

[MrHause]

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: ASSERT_PARAM(4 13), in llm_util.c at line 215 Guru Meditation Error: Core 0 panic'ed (IllegalInstruction). Exception was unhandled.

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.

[SatishSolankeEsp]

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. without OTA or reproduction little tricky. Once you hit the issue again if OTA is impossible for you, I will provide a debug binary for the same.

Thanks, Satish

[chewhs00]

May be related to the fix https://github.com/espressif/esp-idf/issues/6800

[chewhs00]

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 I would like to migrate to a newer idf since v.4.3.1 has an issue with BT pairing with certain Android phones https://github.com/espressif/esp-idf/issues/6800

[esp-zhp]

Does the issue still exist in the latest version?

[chewhs00]

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.

[JD-SX]

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. No matter CONFIG_SW_COEXIST_ENABLE is enable or not, esp32 resets itself in hours.

I (109550) WIFI_MSG: heap remain: 877099 E (110260) NimBLE: ble_adv_list_refresh ble_adv_list is empty I (110260) NimBLE: GAP procedure initiated: discovery;  I (110270) NimBLE: own_addr_type=0 filter_policy=0 passive=0 limited=0 filter_duplicates=0  I (110270) NimBLE: duration=150ms I (110280) NimBLE:  ASSERT_PARAM(4 9), in llm_util.c at line 215 Guru Meditation Error: Core 0 panic'ed (IllegalInstruction). Exception was unhandled. Memory dump at 0x40086f68: 0000f01d 00004136 f01d0000 Core 0 register dump: PC : 0x40086f6f PS : 0x00060830 A0 : 0x8008722e A1 : 0x3ffd2ba0
A2 : 0x00000000 A3 : 0x00000004 A4 : 0x00000009 A5 : 0x3f4f0cdd
A6 : 0x000000d7 A7 : 0xfffffffc A8 : 0x8000814b A9 : 0x3ffd2b10
A10 : 0x00000000 A11 : 0x3ffd2b33 A12 : 0x3ffd2adf A13 : 0x00000035
A14 : 0x00000000 A15 : 0x3ffd2ae4 SAR : 0x00000004 EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000 LBEG : 0x40095a1d LEND : 0x40095a2d LCOUNT : 0xfffffffe

Backtrace: 0x40086f6c:0x3ffd2ba0 0x4008722b:0x3ffd2bc0 0x40111ca9:0x3ffd2be0 0x4010ea27:0x3ffd2c30 0x4010b9de:0x3ffd2c80 0x40019d11:0x3ffd2cc0 0x40055b4d:0x3ffd2ce0 0x400ffecb:0x3ffd2d00 0x40100542:0x3ffd2d20 0x40097f86:0x3ffd2d50

[SatishSolankeEsp]

Hi JD-SX, Could you please share the nimble log as well or the scenario of ble or the role of ble in your application? Could you please give me the app elf ? Please share the IDF commit ID. Thanks, Satish

[esp-zhp]

@JD-SX I can provide a library to fix the issue(workaround). Please provide me with the commit ID you are using.

[JD-SX]

Hi JD-SX, Could you please share the nimble log as well or the scenario of ble or the role of ble in your application? Could you please give me the app elf ? Please share the IDF commit ID. Thanks, Satish

The role of esp32 is ble central Esp32 connects to four nrf52840 and also opens websocket to other server.

I install the idf from the link in espressif website: https://dl.espressif.com/dl/esp-idf/ idf 5.1.2

I will ask my boss to see if I can share the elf file.

[SatishSolankeEsp]

Hi JD-SX could you please try with the attached lib by @zhp0406 , let us know if it helps. Thanks, Satish

[JD-SX]

@JD-SX This is the fixed library. Please replace the libbtdm_app.a file in esp-idf/components/bt/controller/lib_esp32/esp32/. I don't know the specific commit you are using. This commit is based on the latest master branch and was created with the commit ID adc49df. libbtdm_app.zip

Thank you, I will test it and check the result.

[JD-SX]

Hi JD-SX could you please try with the attached lib by @zhp0406 , let us know if it helps. Thanks, Satish

I tested with the libbtdm.a for several hours, and got the same error. idf_py_stdout_output_14560.zip

I (59320) PTO: QQQ: 0 0.076 I (59320) PTO: QQQ: 2 0.094 I (59320) PTO: QQQ: 3 0.076 I (59320) NimBLE: GATT procedure initiated: write;  I (59320) NimBLE: att_handle=16 len=22  I (59330) NimBLE: GATT procedure initiated: write;  I (59330) NimBLE: att_handle=16 len=21  I (59340) NimBLE: GATT procedure initiated: write;  I (59340) NimBLE: att_handle=16 len=21  E (60150) NimBLE: ble_adv_list_refresh ble_adv_list is empty I (60150) NimBLE: GAP procedure initiated: discovery;  I (60150) NimBLE: own_addr_type=0 filter_policy=0 passive=0 limited=0 filter_duplicates=0  I (60160) NimBLE: duration=150ms I (60160) NimBLE:  ASSERT_PARAM(4 9), in llm_util.c at line 215 Guru Meditation Error: Core 0 panic'ed (IllegalInstruction). Exception was unhandled. Memory dump at 0x40086f68: 0000f01d 00004136 f01d0000 Core 0 register dump: PC : 0x40086f6f PS : 0x00060a30 A0 : 0x8008722e A1 : 0x3ffd3350
A2 : 0x00000000 A3 : 0x00000004 A4 : 0x00000009 A5 : 0x3f4f0ccd
A6 : 0x000000d7 A7 : 0xfffffffc A8 : 0x8000814b A9 : 0x3ffd32c0
A10 : 0x00000000 A11 : 0x3ffd32e3 A12 : 0x3ffd328f A13 : 0x00000035
A14 : 0x00000000 A15 : 0x3ffd3294 SAR : 0x00000004 EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000 LBEG : 0x40095a1d LEND : 0x40095a2d LCOUNT : 0xfffffffe

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: xtensa-esp32-elf-addr2line -pfiaC -e build/sta_fw_neo.elf 0x40086f6c:0x3ffd3350 0x4008722b:0x3ffd3370 0x40111c7d:0x3ffd3390 0x4010e9fb:0x3ffd33e0 0x4010b9b2:0x3ffd3430 0x40019d11:0x3ffd3470 0x40055b4d:0x3ffd3490 0x400ffe9f:0x3ffd34b0 0x40100516:0x3ffd34d0 0x40097f86:0x3ffd3500 0x40086f6c: r_assert at ??:? 0x4008722b: r_assert_param at ??:? 0x40111c7d: r_llm_pdu_defer at ??:? 0x4010e9fb: r_lld_pdu_check at ??:? 0x4010b9b2: r_lld_evt_deffered_elt_handler at ??:? 0x40019d11: ?? ??:0 0x40055b4d: ?? ??:0 0x400ffe9f: r_rw_schedule at ??:? 0x40100516: 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]

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; I (382280) NimBLE: att_handle=16 len=21

send start...done: 13 ms, 497 bytes I (382750) WIFI_MSG: heap remain: 877043 I (383080) NimBLE: GAP procedure initiated: discovery; I (383080) NimBLE: own_addr_type=0 filter_policy=0 passive=0 limited=0 filter_duplicates=0 I (383090) NimBLE: duration=150ms I (383090) NimBLE:

ASSERT_PARAM(4 9), in llm_util.c at line 215 Guru Meditation Error: Core 0 panic'ed (IllegalInstruction). Exception was unhandled. Memory dump at 0x40086f68: 0000f01d 00004136 f01d0000 0x40086f68: coex_bt_callback at arch_main.c:?

Core 0 register dump: PC : 0x40086f6f PS : 0x00060030 A0 : 0x8008722e A1 : 0x3ffd3340 0x40086f6f: r_assert at ??:?

A2 : 0x00000000 A3 : 0x00000004 A4 : 0x00000009 A5 : 0x3f4f0be1 A6 : 0x000000d7 A7 : 0xfffffffc A8 : 0x8000814b A9 : 0x3ffd32b0 A10 : 0x00000000 A11 : 0x3ffd32d3 A12 : 0x3ffd327f A13 : 0x00000035 A14 : 0x00000000 A15 : 0x3ffd3284 SAR : 0x00000004 EXCCAUSE: 0x00000000 EXCVADDR: 0x00000000 LBEG : 0x40095a1d LEND : 0x40095a2d LCOUNT : 0xfffffffe 0x40095a1d: strcmp at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/strcmp.S:533

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 0x40086f6c: r_assert at ??:?

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

[esp-zhp]

@JD-SX could you give me your commit id ？I will give you a new lib based on the commit you used.

[esp-zhp]

@JD-SX Before using the new library, you need to delete your previous build. In your first log, the library I provided did not take effect, and the second log is incomplete, as I cannot see the version information. In the future, when you provide logs, please make sure to give me the complete log.thks.

[esp-zhp]

@JD-SX Based on the log you provided earlier, I noticed that you are using version v5.1.2. However, I am not certain about the specific commit you are using. Therefore, I have generated the library for you based on the latest commit (7380f96017424c7be5d8e3229bf81ceb0869cc54) in release/v5.1. Please start another round of testing, and make sure that the library is up to date during the testing process. 6697dfa.zip

I (31) boot: ESP-IDF v5.1.2-691-g7380f96017-dirty 2nd stage bootloader I (31) boot: compile time Feb 6 2024 11:54:18 I (33) boot: Multicore bootloader I (37) boot: chip revision: v3.1 I (41) boot.esp32: SPI Speed : 40MHz I (46) boot.esp32: SPI Mode : DIO I (50) boot.esp32: SPI Flash Size : 2MB I (55) boot: Enabling RNG early entropy source... I (60) boot: Partition Table: I (64) boot: ## Label Usage Type ST Offset Length I (71) boot: 0 nvs WiFi data 01 02 00009000 00006000 I (79) boot: 1 phy_init RF data 01 01 0000f000 00001000 I (86) boot: 2 factory factory app 00 00 00010000 00100000 I (94) boot: End of partition table I (98) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=20cach (134316) map I (155) esp_image: segment 1: paddr=00030cd4 vaddr=3ffbdb60 size=049d8h ( 18904) load I (162) esp_image: segment 2: paddr=000356b4 vaddr=40080000 size=0a964h ( 43364) load I (181) esp_image: segment 3: paddr=00040020 vaddr=400d0020 size=82288h (533128) map I (373) esp_image: segment 4: paddr=000c22b0 vaddr=4008a964 size=0e04ch ( 57420) load I (410) boot: Loaded app from partition at offset 0x10000 I (410) boot: Disabling RNG early entropy source... I (422) cpu_start: Multicore app I (422) cpu_start: Pro cpu up. I (422) cpu_start: Starting app cpu, entry point is 0x4008137c 0x4008137c: call_start_cpu1 at /home/zhanghaipeng/esp/esp-idf/components/esp_system/port/cpu_start.c:159

I (0) cpu_start: App cpu up. I (440) cpu_start: Pro cpu start user code I (440) cpu_start: cpu freq: 160000000 Hz I (440) cpu_start: Application information: I (445) cpu_start: Project name: gatt_server_demos I (450) cpu_start: App version: qa-test-v5.1.3-20240129-7-g7380 I (457) cpu_start: Compile time: Feb 6 2024 11:54:13 I (464) cpu_start: ELF file SHA256: c997416f... I (469) cpu_start: ESP-IDF: v5.1.2-691-g7380f96017-dirty I (476) cpu_start: Min chip rev: v0.0 I (480) cpu_start: Max chip rev: v3.99 I (485) cpu_start: Chip rev: v3.1 I (490) heap_init: Initializing. RAM available for dynamic allocation: I (497) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM I (503) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM I (509) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM I (515) heap_init: At 3FFC70A0 len 00018F60 (99 KiB): DRAM I (522) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (528) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (534) heap_init: At 400989B0 len 00007650 (29 KiB): IRAM I (542) spi_flash: detected chip: gd I (545) spi_flash: flash io: dio W (549) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header. I (563) coexist: coex firmware version: 77cd7f8 I (568) app_start: Starting scheduler on CPU0 I (572) app_start: Starting scheduler on CPU1 I (572) main_task: Started on CPU0 I (582) main_task: Calling app_main() I (602) BTDM_INIT: BT controller compile version [6697dfa] I (602) BTDM_INIT: Bluetooth MAC: 08:b6:1f:ed:4e:42 I (612) phy_init: phy_version 4791,2c4672b,Dec 20 2023,16:06:06

[JD-SX]

@JD-SX Based on the log you provided earlier, I noticed that you are using version v5.1.2. However, I am not certain about the specific commit you are using. Therefore, I have generated the library for you based on the latest commit (7380f96) in release/v5.1. Please start another round of testing, and make sure that the library is up to date during the testing process. 6697dfa.zip

I (31) boot: ESP-IDF v5.1.2-691-g7380f96017-dirty 2nd stage bootloader I (31) boot: compile time Feb 6 2024 11:54:18 I (33) boot: Multicore bootloader I (37) boot: chip revision: v3.1 I (41) boot.esp32: SPI Speed : 40MHz I (46) boot.esp32: SPI Mode : DIO I (50) boot.esp32: SPI Flash Size : 2MB I (55) boot: Enabling RNG early entropy source... I (60) boot: Partition Table: I (64) boot: ## Label Usage Type ST Offset Length I (71) boot: 0 nvs WiFi data 01 02 00009000 00006000 I (79) boot: 1 phy_init RF data 01 01 0000f000 00001000 I (86) boot: 2 factory factory app 00 00 00010000 00100000 I (94) boot: End of partition table I (98) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=20cach (134316) map I (155) esp_image: segment 1: paddr=00030cd4 vaddr=3ffbdb60 size=049d8h ( 18904) load I (162) esp_image: segment 2: paddr=000356b4 vaddr=40080000 size=0a964h ( 43364) load I (181) esp_image: segment 3: paddr=00040020 vaddr=400d0020 size=82288h (533128) map I (373) esp_image: segment 4: paddr=000c22b0 vaddr=4008a964 size=0e04ch ( 57420) load I (410) boot: Loaded app from partition at offset 0x10000 I (410) boot: Disabling RNG early entropy source... I (422) cpu_start: Multicore app I (422) cpu_start: Pro cpu up. I (422) cpu_start: Starting app cpu, entry point is 0x4008137c 0x4008137c: call_start_cpu1 at /home/zhanghaipeng/esp/esp-idf/components/esp_system/port/cpu_start.c:159

I (0) cpu_start: App cpu up. I (440) cpu_start: Pro cpu start user code I (440) cpu_start: cpu freq: 160000000 Hz I (440) cpu_start: Application information: I (445) cpu_start: Project name: gatt_server_demos I (450) cpu_start: App version: qa-test-v5.1.3-20240129-7-g7380 I (457) cpu_start: Compile time: Feb 6 2024 11:54:13 I (464) cpu_start: ELF file SHA256: c997416f... I (469) cpu_start: ESP-IDF: v5.1.2-691-g7380f96017-dirty I (476) cpu_start: Min chip rev: v0.0 I (480) cpu_start: Max chip rev: v3.99 I (485) cpu_start: Chip rev: v3.1 I (490) heap_init: Initializing. RAM available for dynamic allocation: I (497) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM I (503) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM I (509) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM I (515) heap_init: At 3FFC70A0 len 00018F60 (99 KiB): DRAM I (522) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (528) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (534) heap_init: At 400989B0 len 00007650 (29 KiB): IRAM I (542) spi_flash: detected chip: gd I (545) spi_flash: flash io: dio W (549) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header. I (563) coexist: coex firmware version: 77cd7f8 I (568) app_start: Starting scheduler on CPU0 I (572) app_start: Starting scheduler on CPU1 I (572) main_task: Started on CPU0 I (582) main_task: Calling app_main() I (602) BTDM_INIT: BT controller compile version [6697dfa] I (602) BTDM_INIT: Bluetooth MAC: 08:b6:1f:ed:4e:42 I (612) phy_init: phy_version 4791,2c4672b,Dec 20 2023,16:06:06

Thank you. I'll perform a fullclean, apply the new library, and then proceed with the next round of testing.

[JD-SX]

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 cmd.exe /C "cd . && C:\Users\jdhua.espressif\tools\xtensa-esp32-elf\esp-12.2.0_20230208\xtensa-esp32-elf\bin\xtensa-esp32-elf-g++.exe -mlongcalls -Wno-frame-address -Wl,--cref -Wl,--defsym=IDF_TARGET_ESP32=0 -Wl,--Map=C:/SiriuXense/Dev/github/fw-siriux_baby_station/fw/sta_fw_neo/build/sta_fw_neo.map -Wl,--no-warn-rwx-segments -fno-rtti -fno-lto -Wl,--gc-sections -Wl,--warn-common -T esp32.peripherals.ld -T esp32.rom.ld -T esp32.rom.api.ld -T esp32.rom.libgcc.ld -T esp32.rom.newlib-data.ld -T esp32.rom.syscalls.ld -T memory.ld -T sections.ld @CMakeFiles\sta_fw_neo.elf.rsp -o sta_fw_neo.elf && cd ." c:/users/jdhua/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld.exe: C:/Users/jdhua/.espressif/frameworks/esp-idf-v5.1.2/components/bt/controller/lib_esp32/esp32\libbtdm_app.a(rf_espressif.o):(.iram1.26+0x0): undefined reference to phy_bt_ifs_set' c:/users/jdhua/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld.exe: C:/Users/jdhua/.espressif/frameworks/esp-idf-v5.1.2/components/bt/controller/lib_esp32/esp32\libbtdm_app.a(rf_espressif.o):(.iram1.26+0x13): undefined reference tophy_bt_ifs_set' c:/users/jdhua/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld.exe: C:/Users/jdhua/.espressif/frameworks/esp-idf-v5.1.2/components/bt/controller/lib_esp32/esp32\libbtdm_app.a(lm_sco.o):(.text+0x4): undefined reference to lm_nb_sync_active' c:/users/jdhua/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld.exe: C:/Users/jdhua/.espressif/frameworks/esp-idf-v5.1.2/components/bt/controller/lib_esp32/esp32\libbtdm_app.a(lm_sco.o):(.text+0x8): undefined reference tolm_sync_nego' c:/users/jdhua/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld.exe: C:/Users/jdhua/.espressif/frameworks/esp-idf-v5.1.2/components/bt/controller/lib_esp32/esp32\libbtdm_app.a(lm_sco.o):(.text+0xc): undefined reference to lm_sync_conf' c:/users/jdhua/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld.exe: C:/Users/jdhua/.espressif/frameworks/esp-idf-v5.1.2/components/bt/controller/lib_esp32/esp32\libbtdm_app.a(lm_sco.o):(.text+0x10): undefined reference tolm_nego_cnt' c:/users/jdhua/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld.exe: C:/Users/jdhua/.espressif/frameworks/esp-idf-v5.1.2/components/bt/controller/lib_esp32/esp32\libbtdm_app.a(lm_sco.o):(.text+0x14): undefined reference to lm_nego_cntl' c:/users/jdhua/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld.exe: C:/Users/jdhua/.espressif/frameworks/esp-idf-v5.1.2/components/bt/controller/lib_esp32/esp32\libbtdm_app.a(lm_sco.o):(.text+0x18): undefined reference tolm_nego_max_cnt' c:/users/jdhua/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld.exe: C:/Users/jdhua/.espressif/frameworks/esp-idf-v5.1.2/components/bt/controller/lib_esp32/esp32\libbtdm_app.a(lm_sco.o):(.text+0x1c): undefined reference to `lm_nego_pkt_used' collect2.exe: error: ld returned 1 exit status ninja: build stopped: subcommand failed. ninja failed with exit code 1, output of the command is in the C:\SiriuXense\Dev\github\fw-siriux_baby_station\fw\sta_fw_neo\build\log\idf_py_stderr_output_1552 and C:\SiriuXense\Dev\github\fw-siriux_baby_station\fw\sta_fw_neo\build\log\idf_py_stdout_output_1552

=========================================================

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 error: cannot spawn less: No such file or directory commit 482a8fb2d78e3b58eb21b26da8a5bedf90623213 (HEAD, tag: v5.1.2) Author: Aditya Patwardhan aditya.patwardhan@espressif.com Date: Fri Nov 10 08:08:53 2023 +0550

change(version): Update version to 5.1.2

diff --git a/components/esp_common/include/esp_idf_version.h b/components/esp_common/include/esp_idf_version.h index 824079ecd8..55adeb9e59 100644 --- a/components/esp_common/include/esp_idf_version.h +++ b/components/esp_common/include/esp_idf_version.h @@ -15,7 +15,7 @@ extern "C" { /* Minor version number (x.X.x) /

define ESP_IDF_VERSION_MINOR 1

/* Patch version number (x.x.X) / -#define ESP_IDF_VERSION_PATCH 1 +#define ESP_IDF_VERSION_PATCH 2

/**

• Macro to convert IDF version number into an integer diff --git a/tools/cmake/version.cmake b/tools/cmake/version.cmake index 3547139a5d..aa6435c858 100644 --- a/tools/cmake/version.cmake +++ b/tools/cmake/version.cmake @@ -1,5 +1,5 @@ set(IDF_VERSION_MAJOR 5) set(IDF_VERSION_MINOR 1) -set(IDF_VERSION_PATCH 1) +set(IDF_VERSION_PATCH 2)

  set(ENV{IDF_VERSION} "${IDF_VERSION_MAJOR}.${IDF_VERSION_MINOR}.${IDF_VERSION_PATCH}")

commit 9f2a2dbda6c91c93d5d75736d3676455e532f40f Merge: 5b3a8ac503 287255026e Author: Jiang Jiang Jian jack@espressif.com Date: Thu Nov 9 16:37:36 2023 +0800

Merge branch 'bugfix/ble_update_lib_1027_5.1' into 'release/v5.1'

ble: update c6 h2 lib to 5bd7cb83, c2 lib to 1d31e175

See merge request espressif/esp-idf!26711

[esp-zhp]

@JD-SX The commit you're using doesn't seem right. The lib I provided to you is based on the latest commit 7380f96 from the release/v5.1 branch.

v5.1.2-691-g7380f96017

[JD-SX]

idf_py_stdout_output_1388.zip @zhp0406

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.

[esp-zhp]

@JD-SX Ok, 1-could you please tell me in what scenario this issue occurs? 2-Can you assist me in reproducing the problem? 3-What actions were taken with WiFi and BLE respectively? If only BLE is running, will this issue still occur? Thank you very much.

[JD-SX]

@JD-SX Ok, 1-could you please tell me in what scenario this issue occurs? 2-Can you assist me in reproducing the problem? 3-What actions were taken with WiFi and BLE respectively? If only BLE is running, will this issue still occur? Thank you very much.

1. 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.

2. The ble & wifi coexist issue is solved by adopted the library(6697dfa). The new issue is rising when destorying websocket; might be stack overflow.

3. 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. I well test ble only situation if the same issue occurs.

[Indastri]

Closing the issue as solved, if you will encounter any more issues feel free to reopen this or create a new issue.

Cheers!