SPI slave long wait period panicks system

Ian777
Posts: 21
Joined: Sun Jun 17, 2018 11:31 pm

SPI slave long wait period panicks system

Postby Ian777 » Fri Apr 19, 2019 4:24 am

Hey everyone,

I have a multi_master spi going.
When the one master takes a long time to communicate with the esp32 the device panicks.

Essentially the spi_slave transmission call is done with the following:

Code: Select all

ret=spi_slave_transmit(HSPI_HOST, &t, portMAX_DELAY);
I know that it is this causing this as if I remove the call to this, no core panic occurs, furthermore if I ensure that the other micro transmits faster, this also doesn't happen and the spi operates normally.

By faster I don't meant he frequency of transmission but rather that after the above function is called the other mcu sends data via spi within seconds instead of 10.

I have a feeling some watchdog might be causing the panic due to the spi just waiting, although i haven't manually configured a watchdog in my code.

Does anyone know what could be causing this or might have experienced anything similar?

any help will really be appreciated

ESP_Sprite
Posts: 9764
Joined: Thu Nov 26, 2015 4:08 am

Re: SPI slave long wait period panicks system

Postby ESP_Sprite » Fri Apr 19, 2019 11:16 am

Can you post the contents of the panic (and if possible, the backtrace)?

Ian777
Posts: 21
Joined: Sun Jun 17, 2018 11:31 pm

Re: SPI slave long wait period panicks system

Postby Ian777 » Fri Apr 19, 2019 2:36 pm

ESP_Sprite wrote:
Fri Apr 19, 2019 11:16 am
Can you post the contents of the panic (and if possible, the backtrace)?
Hi! Here's the coredump:

espcoredump.py v0.3-dev
INFO:Read TCB 356 bytes @ 0x3ffbb9b4
INFO:Read stack 1148 bytes @ 0x3ffbb530
INFO:Stack start_end: 0x3ffbb530 @ 0x3ffbb9ac
INFO:Read TCB 356 bytes @ 0x3ffbc88c
INFO:Read stack 420 bytes @ 0x3ffbc6e0
INFO:Stack start_end: 0x3ffbc6e0 @ 0x3ffbc884
INFO:Read TCB 356 bytes @ 0x3ffbc120
INFO:Read stack 424 bytes @ 0x3ffbbf70
INFO:Stack start_end: 0x3ffbbf70 @ 0x3ffbc118
INFO:Read TCB 356 bytes @ 0x3ffbf8e8
INFO:Read stack 512 bytes @ 0x3ffbf6e0
INFO:Stack start_end: 0x3ffbf6e0 @ 0x3ffbf8e0
INFO:Read TCB 356 bytes @ 0x3ffbd2ec
INFO:Read stack 420 bytes @ 0x3ffbd140
INFO:Stack start_end: 0x3ffbd140 @ 0x3ffbd2e4
INFO:Read TCB 356 bytes @ 0x3ffba268
INFO:Read stack 416 bytes @ 0x3ffba0c0
INFO:Stack start_end: 0x3ffba0c0 @ 0x3ffba260
INFO:Read TCB 356 bytes @ 0x3ffc12a8
INFO:Read stack 496 bytes @ 0x3ffc10b0
INFO:Stack start_end: 0x3ffc10b0 @ 0x3ffc12a0
INFO:Read TCB 356 bytes @ 0x3ffafafc
INFO:Read stack 420 bytes @ 0x3ffaf950
INFO:Stack start_end: 0x3ffaf950 @ 0x3ffafaf4
INFO:Read TCB 356 bytes @ 0x3ffc29b4
INFO:Read stack 492 bytes @ 0x3ffc27c0
INFO:Stack start_end: 0x3ffc27c0 @ 0x3ffc29ac
INFO:Read TCB 356 bytes @ 0x3ffafe64
INFO:Read stack 424 bytes @ 0x3ffb9c60
INFO:Stack start_end: 0x3ffb9c60 @ 0x3ffb9e08
===============================================================
==================== ESP32 CORE DUMP START ====================

================== CURRENT THREAD REGISTERS ===================
/builds/idf/crosstool-NG/.build/src/gdb-7.10/gdb/findvar.c:290: internal-error: value_of_register_lazy: Assertion `frame_id_p (get_frame_id (frame))' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
/builds/idf/crosstool-NG/.build/src/gdb-7.10/gdb/findvar.c:290: internal-error: value_of_register_lazy: Assertion `frame_id_p (get_frame_id (frame))' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
ERROR:GDB exited (None / None)!
ERROR:Problem occured! GDB exited, restart it.
Reading symbols from /home/user/Desktop/esp-idf-template/build/app-template.elf...done.
[New <main task>]
[New process 1]
[New process 2]
[New process 3]
[New process 4]
[New process 5]
[New process 6]
[New process 7]
[New process 8]
[New process 9]
[Current thread is 1 (<main task>)]

==================== CURRENT THREAD STACK =====================
#-1 0x400014fd in ?? ()
Backtrace stopped: Cannot access memory at address 0x400014fd

======================== THREADS INFO =========================
Id Target Id Frame
10 process 9 0x4008e5e1 in prvNotifyQueueSetContainer (pxQueue=0x3ffafe10, xCopyPosition=0) at /home/user/esp/esp-idf/components/freertos/queue.c:2553
9 process 8 0x4008e5e1 in prvNotifyQueueSetContainer (pxQueue=0x3ffc14c8, xCopyPosition=1073490160) at /home/user/esp/esp-idf/components/freertos/queue.c:2553
8 process 7 0x4008e5e1 in prvNotifyQueueSetContainer (pxQueue=0x3ffaea50, xCopyPosition=0) at /home/user/esp/esp-idf/components/freertos/queue.c:2553
7 process 6 0x40081574 in esp_intr_noniram_disable () at /home/user/esp/esp-idf/components/esp32/intr_alloc.c:865
6 process 5 0x4008e5e1 in prvNotifyQueueSetContainer (pxQueue=0x3ffb9e10, xCopyPosition=0) at /home/user/esp/esp-idf/components/freertos/queue.c:2553
5 process 4 0x40090210 in vTaskPlaceOnUnorderedEventList (pxEventList=0x3ffb444c <g_cnxMgr+988>, xItemValue=<optimized out>, xTicksToWait=1) at /home/user/esp/esp-idf/components/freertos/tasks.c:3008
4 process 3 0x4008e5e1 in prvNotifyQueueSetContainer (pxQueue=0x3ffba610, xCopyPosition=1073477680) at /home/user/esp/esp-idf/components/freertos/queue.c:2553
3 process 2 0x401677fe in ?? ()
2 process 1 0x401677fe in ?? ()
* 1 <main task> 0x400014fd in ?? ()

======================= ALL MEMORY REGIONS ========================
Name Address Size Attrs
.rtc.text 0x400c0000 0x0 RW
.rtc.dummy 0x3ff80000 0x0 RW
.rtc.force_fast 0x3ff80000 0x0 RW
.rtc_noinit 0x50000000 0x0 RW
.rtc.force_slow 0x50000000 0x0 RW
.iram0.vectors 0x40080000 0x400 R XA
.iram0.text 0x40080400 0x11700 RWXA
.dram0.data 0x3ffb0000 0x2e00 RW A
.noinit 0x3ffb2e00 0x0 RW
.flash.rodata 0x3f400020 0x1dbd0 RW A
.flash.text 0x400d0018 0x727c8 R XA
.coredump.tasks.data 0x3ffbb9b4 0x164 RW
.coredump.tasks.data 0x3ffbb530 0x47c RW
.coredump.tasks.data 0x3ffbc88c 0x164 RW
.coredump.tasks.data 0x3ffbc6e0 0x1a4 RW
.coredump.tasks.data 0x3ffbc120 0x164 RW
.coredump.tasks.data 0x3ffbbf70 0x1a8 RW
.coredump.tasks.data 0x3ffbf8e8 0x164 RW
.coredump.tasks.data 0x3ffbf6e0 0x200 RW
.coredump.tasks.data 0x3ffbd2ec 0x164 RW
.coredump.tasks.data 0x3ffbd140 0x1a4 RW
.coredump.tasks.data 0x3ffba268 0x164 RW
.coredump.tasks.data 0x3ffba0c0 0x1a0 RW
.coredump.tasks.data 0x3ffc12a8 0x164 RW
.coredump.tasks.data 0x3ffc10b0 0x1f0 RW
.coredump.tasks.data 0x3ffafafc 0x164 RW
.coredump.tasks.data 0x3ffaf950 0x1a4 RW
.coredump.tasks.data 0x3ffc29b4 0x164 RW
.coredump.tasks.data 0x3ffc27c0 0x1ec RW
.coredump.tasks.data 0x3ffafe64 0x164 RW
.coredump.tasks.data 0x3ffb9c60 0x1a8 RW

===================== ESP32 CORE DUMP END =====================
===============================================================


Here's the backtrace:

Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandle d.
Core 0 register dump:
PC : 0x400014fd PS : 0x00060f30 A0 : 0x800d5440 A1 : 0x3f fbb5f0
A2 : 0x00000000 A3 : 0xfffffffc A4 : 0x000000ff A5 : 0x00 00ff00
A6 : 0x00ff0000 A7 : 0xff000000 A8 : 0x00000000 A9 : 0x3f fbb5f0
A10 : 0x00000003 A11 : 0x00060f23 A12 : 0x00060f20 A13 : 0x00 000080
A14 : 0x00000001 A15 : 0x00000000 SAR : 0x00000013 EXCCAUSE: 0x00 00001c
EXCVADDR: 0x00000000 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xff ffffff

Backtrace: 0x400014fd:0x3ffbb5f0 0x400d543d:0x3ffbb600 0x400d54d5:0x3ffbb640 0x4 00d40a8:0x3ffbb660 0x400d2e36:0x3ffbb760 0x400d0db2:0x3ffbb900 0x4008da85:0x3ffb
b920


Any help with this will really be appreciated.

I'm not sure whether the coredump will be much help as I've been pulling my hair out with it. I've made a post in reference to it here:

viewtopic.php?f=13&t=10204

Who is online

Users browsing this forum: No registered users and 105 guests