esp-idf: Guru Meditation Error: Core 0 panic'ed (IllegalInstruction). (IDFGH-11102)
Answers checklist.
- I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
- I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
- I have searched the issue tracker for a similar issue and not found a similar issue.
IDF version.
v5.1.1
Operating System used.
Linux
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
Olimex ESP32-POE-ISO Wroom 32E
Power Supply used.
USB
What is the expected behavior?
No core panic
What is the actual behavior?
I am using ESP32 in gattc mode, and it sometimes panics, when BLE signal is on the edge of disconnect. I recently updated esp-idf version from 4.4.5 to 5.1.1, but this issue still persists.
Steps to reproduce.
- Setup BLE Gattc.
- Put server device in near-out-of-range location.
Debug Logs.
ASSERT_PARAM(0 0), in lld_evt.c at line 1487
Guru Meditation Error: Core 0 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x4008fc94: f01d020c 00004136 f01d0000
0x4008fc94: btdm_sleep_check_duration at /home/matas/esp/esp-idf/components/bt/controller/esp32/bt.c:909
Core 0 register dump:
PC : 0x4008fc9b PS : 0x00060c34 A0 : 0x80083baa A1 : 0x3ffc1be0
0x4008fc9b: r_assert at /home/matas/esp/esp-idf/components/bt/controller/esp32/bt.c:1849
A2 : 0x00000000 A3 : 0x00000000 A4 : 0x00000000 A5 : 0x3f410046
A6 : 0x000005cf A7 : 0xfffffffb A8 : 0x8000814b A9 : 0x3ffc1b50
A10 : 0x00000000 A11 : 0x3ffc1b74 A12 : 0x3ffc1b1f A13 : 0x00000037
A14 : 0x00000000 A15 : 0x3ffc1b25 SAR : 0x00000004 EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000 LBEG : 0x400012c5 LEND : 0x400012d5 LCOUNT : 0xfffffffe
0x400012c5: strcmp in ROM
0x400012d5: strcmp in ROM
Backtrace: 0x4008fc98:0x3ffc1be0 0x40083ba7:0x3ffc1c00 0x4008778f:0x3ffc1c20 0x4008416e:0x3ffc1c60 0x4008a0de:0x3ffc1c80 0x4008ad3f:0x3ffc1ca0 0x40083479:0x3ffc1cc0 0x400833e5:0x3ffc1ce0 0x400833c7:0x00000000 |<-CORRUPTED
0x4008fc98: r_assert at /home/matas/esp/esp-idf/components/bt/controller/esp32/bt.c:1848
0x40083ba7: r_assert_param at ??:?
0x4008778f: r_lld_evt_schedule at ??:?
0x4008416e: r_ea_finetimer_isr at ??:?
0x4008a0de: r_rwbt_isr at ??:?
0x4008ad3f: r_rwbtdm_isr_wrapper at intc.c:?
0x40083479: hli_c_handler at /home/matas/esp/esp-idf/components/bt/controller/esp32/hli_api.c:92
0x400833e5: _highint4_stack_switch at /home/matas/esp/esp-idf/components/bt/controller/esp32/hli_vectors.S:177
0x400833c7: xt_highint4 at /home/matas/esp/esp-idf/components/bt/controller/esp32/hli_vectors.S:161
More Information.
No response
About this issue
- Original URL
- State: open
- Created 9 months ago
- Comments: 34
@mjaneczek During the channel map update, some of our logic is incorrect, leading to the occurrence of this issue. The problem tends to arise sporadically during channel map updates. Therefore, if the signal is weak, and there is more interference, the frequency of channel map updates is higher, increasing the likelihood of encountering the issue.
We have already fixed this issue in the master branch, and the commit ID for the master branch is 9c40585b23f8aadda6797dddd78c00008368f1f5.
We are currently in the process of backporting this fix to other branches.
@matislovas Hi， The MR has been submitted and will be merged into all branches. Currently, it is in the testing process, and this process will likely take around 10 days. After the MR is completed, we will inform you of the commit.
Yeah, now it builds! Will try for couple days and will get back with results.
@matislovas sorry for that,I seem to have made some mistakes,I will check …
Sent once again zipped. And also sent you wetransfer link, if the zipped one won’t work.
@matislovas sure,You can send it to me via email and let me know the reproduction process. My email is [zhanghaipeng@espressif.com].