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

[chegewara]

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.

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=<optimized out>) at /home/chegewara/programming/esp-idf/master/components/newlib/locks.c:321
#6  0x4803c9ec in _vfprintf_r (data=0x4ff1eb74, fp=0x4ff1be5c, fmt0=0x48064804 "", ap=<optimized out>) 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]

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]

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]

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