chegewara commented 1 day ago

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Hi, i have some test app and im not sure which espressif component is causing crash, because backtrace is not clear about it. Here is the story:

TCP/IP over USB - using tinyusb, esp_tinyusb and iperf components
when SPIRAM is disabled then all is ok, and there is no crash

when i enable SPIRAM, experimental mode, 200MHz then it crash with this backtrace


W (58252) iperf: tcp server recv error, error code: 128, reason: Socket is not connected
I (58252) iperf: TCP Socket server is closed.
I (58262) iperf: iperf exit
Guru Meditation Error: Core  1 panic'ed (Stack protection fault).

Detected in task "IDLE1" at 0x4ff0d858 --- 0x4ff0d858: xTaskGetCurrentTaskHandle at /home/chegewara/programming/esp-idf/master/components/freertos/FreeRTOS-Kernel/tasks.c:4961

Stack pointer: 0x4ff1e510 Stack bounds: 0x4ff1e514 - 0x4ff1eb10

--- Stack dump detected Core 1 register dump: MEPC : 0x4ff0b436 RA : 0x4ff0d862 SP : 0x4ff1e510 GP : 0x4ff14580
--- 0x4ff0b436: xPortSetInterruptMaskFromISR at /home/chegewara/programming/esp-idf/master/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:488 0x4ff0d862: rv_utils_get_core_id at /home/chegewara/programming/esp-idf/master/components/riscv/include/riscv/rv_utils.h:75 (inlined by) esp_cpu_get_core_id at /home/chegewara/programming/esp-idf/master/components/esp_hw_support/include/esp_cpu.h:129 (inlined by) xPortGetCoreID at /home/chegewara/programming/esp-idf/master/components/freertos/FreeRTOS-Kernel/portable/riscv/include/freertos/portmacro.h:442 (inlined by) xTaskGetCurrentTaskHandle at /home/chegewara/programming/esp-idf/master/components/freertos/FreeRTOS-Kernel/tasks.c:4975

TP : 0x4ff1eaf0 T0 : 0x4fc0aa86 T1 : 0x00000000 T2 : 0x00000000
S0/FP : 0x4ff1bff4 S1 : 0xffffffff A0 : 0x1f000000 A1 : 0xffffffff
A2 : 0x00000004 A3 : 0x7f000000 A4 : 0x00010088 A5 : 0x00010080
A6 : 0x00000002 A7 : 0x00000000 S2 : 0x00000000 S3 : 0xffffffff
S4 : 0x00000000 S5 : 0x00000000 S6 : 0x00000000 S7 : 0x00000000
S8 : 0x00000000 S9 : 0x00000000 S10 : 0x00000000 S11 : 0x00000000
T3 : 0x00000000 T4 : 0x00000000 T5 : 0x00000000 T6 : 0x00000000
MSTATUS : 0x00011880 MTVEC : 0x4ff00003 MCAUSE : 0x0000001b MTVAL : 0x00000000
--- 0x4ff00003: _vector_table at ??:?

MHARTID : 0x00000001

--- Backtrace:

xPortSetInterruptMaskFromISR () at /home/chegewara/programming/esp-idf/master/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:487 487 return prev_int_level;

0 xPortSetInterruptMaskFromISR () at /home/chegewara/programming/esp-idf/master/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:487

1 0x4ff0d862 in xTaskGetCurrentTaskHandle () at /home/chegewara/programming/esp-idf/master/components/freertos/FreeRTOS-Kernel/tasks.c:4973

2 0x4ff0b05c in xQueueTakeMutexRecursive (xMutex=xMutex@entry=0x4ff1bff4, xTicksToWait=xTicksToWait@entry=4294967295) at /home/chegewara/programming/esp-idf/master/components/freertos/FreeRTOS-Kernel/queue.c:828

3 0x4ff01a72 in lock_acquire_generic (lock=lock@entry=0x4ff1e57c, delay=delay@entry=4294967295, mutex_type=mutex_type@entry=4 '\004') at /home/chegewara/programming/esp-idf/master/components/newlib/locks.c:146

4 0x4ff01b92 in _lock_acquire_recursive (lock=lock@entry=0x4ff1e57c) at /home/chegewara/programming/esp-idf/master/components/newlib/locks.c:162

5 0x4ff01c68 in __retarget_lock_acquire_recursive (lock=) at /home/chegewara/programming/esp-idf/master/components/newlib/locks.c:321

6 0x4803c9ec in _vfprintf_r (data=0x4ff1eb74, fp=0x4ff1be5c, fmt0=0x48064804 "", ap=) at /builds/idf/crosstool-NG/.build/riscv32-esp-elf/src/newlib/newlib/libc/stdio/vfprintf.c:846

7 0x00000000 in ?? ()

Backtrace stopped: frame did not save the PC



It is not a problem with stack, because it was initially 4k and now is set to 10k.

I hope this backtrace can help someone to find the cause, if not i will try to provide some more info on request.

Thanks

SoucheSouche commented 1 day ago

Hi @chegewara, we will take a look at your issue. Could you please let us know about the chip and the esp-idf version you are using? And also a way we could reproduce the issue would be more than welcomed :) It does look like the stack pointer gets out of the stack boundaries and trigger the panic handler with the stack protection fault. (See https://docs.espressif.com/projects/esp-idf/en/latest/esp32c2/api-guides/fatal-errors.html#hardware-stack-guard)

chegewara commented 1 day ago

Yes, of course, i missed it. It is esp32-p4 ev board with chip revision: v0.1. It is on master branch and some commits earlier too.

Here is test code, sorry for mess in it: https://github.com/chegewara/p4-crash-test

Thanks

PS i hope i dont have to explain how to run iperf example running on it? its enough to connect board to PC with USB cable and IP on it is 192.168.4.1

SoucheSouche commented 7 hours ago

Hi @chegewara, Thanks a lot for the provided info, I will take a look at it.

espressif / esp-idf

[esp32-p4] unexpected crash when SPIRAM enabled, no crash when disabled in the same code (IDFGH-13803) #14660