Guru Meditation Error: Core 0 panic'ed

[josef2600]

in board manger v 2.0.15 we have this:

Rebooting...
⸮ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x2b (SPI_FAST_FLASH_BOOT)
Saved PC:0x4037736c
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3808,len:0x4bc
load:0x403c9700,len:0xbd8
load:0x403cc700,len:0x2a0c
entry 0x403c98d0
Guru Meditation Error: Core  0 panic'ed (StoreProhibited). Exception was unhandled.

Core  0 register dump:
PC      : 0x420037ee  PS      : 0x00060a30  A0      : 0x820038c8  A1      : 0x3fcebbd0  
A2      : 0x00000010  A3      : 0x00000000  A4      : 0x60004000  A5      : 0x0000000b  
A6      : 0x000000ff  A7      : 0x00000000  A8      : 0x08000000  A9      : 0x3fcebba0  
A10     : 0x3fc95938  A11     : 0x00000001  A12     : 0xffffffff  A13     : 0x00000000  
A14     : 0x00004000  A15     : 0x3fc91e3c  SAR     : 0x00000010  EXCCAUSE: 0x0000001d  
EXCVADDR: 0x00000010  LBEG    : 0x42005d1c  LEND    : 0x42005d7f  LCOUNT  : 0x00000000  


Backtrace: 0x420037eb:0x3fcebbd0 0x420038c5:0x3fcebc00 0x420025a9:0x3fcebc20 0x42006926:0x3fcebc50

esp32s3 Demo_3D_cube.ino ST7796 with or without touch any frequency!

but in board manger v 2.0.14 it works.

[HSBallina]

Same issue as #3284 and #3289. There were some breaking changes in 2.0.15.

[dbtronics]

For anyone still tackling with this issue. Change your ESP32 board package back to 2.0.14. As that is the package compatible with this TFT_eSPI and will solve the infinite reset loop problem.

[zalexzperez]

Oh man, I lost an hour over this. It was working fine on PlatformIO, but not on Arduino IDE.

[josef2600]

Oh man, I lost an hour over this. It was working fine on PlatformIO, but not on Arduino IDE.

i went mad over it! i was going crazy, it was working 2 days ago, now it doesn't work at all! what the hell did i do?!! well, i guess when you work with china things, this is what happens! they erase themselves too!

[Robecq]

I've run into the same issue, but only when I try to initialize the camera on a wrover board and send the frame to the tft. The graphic test example works fine on its own. It doesn't seem to be able to access psram properly

[josef2600]

it has been a long discussion about it. as far as i understand and tested it, all of it caused by the defining of the SPI driver. i don't know why they did it, but i think it is because they wanted to use DMA via I2S. i tried to thinker with it, but i got bored! any way, if you want, it is in "TFT_eSPI\Processors" folder. whatever processor that you are using. like in "TFT_eSPI_ESP32_S3.h" the priblem rises in this part:

// Processor specific code used by SPI bus transaction startWrite and endWrite functions
#if !defined (ESP32_PARALLEL)
  #define _spi_cmd       (volatile uint32_t*)(SPI_CMD_REG(SPI_PORT))
  #define _spi_user      (volatile uint32_t*)(SPI_USER_REG(SPI_PORT))
  #define _spi_mosi_dlen (volatile uint32_t*)(SPI_MOSI_DLEN_REG(SPI_PORT))
  #define _spi_w         (volatile uint32_t*)(SPI_W0_REG(SPI_PORT))

  #if (TFT_SPI_MODE == SPI_MODE1) || (TFT_SPI_MODE == SPI_MODE2)
    #define SET_BUS_WRITE_MODE *_spi_user = SPI_USR_MOSI | SPI_CK_OUT_EDGE
    #define SET_BUS_READ_MODE  *_spi_user = SPI_USR_MOSI | SPI_USR_MISO | SPI_DOUTDIN | SPI_CK_OUT_EDGE
  #else
    #define SET_BUS_WRITE_MODE *_spi_user = SPI_USR_MOSI
    #define SET_BUS_READ_MODE  *_spi_user = SPI_USR_MOSI | SPI_USR_MISO | SPI_DOUTDIN
  #endif
#else

to be more specific, in here:

  #define _spi_cmd       (volatile uint32_t*)(SPI_CMD_REG(SPI_PORT))
  #define _spi_user      (volatile uint32_t*)(SPI_USER_REG(SPI_PORT))
  #define _spi_mosi_dlen (volatile uint32_t*)(SPI_MOSI_DLEN_REG(SPI_PORT))
  #define _spi_w         (volatile uint32_t*)(SPI_W0_REG(SPI_PORT))

these are apparently hardware definitions. but probably changed some time before 2.0.14. since it has problem with all other drivers for spi. good luck.

[josef2600]

changing ESP32 board package back to 2.0.14 is not a solve! please fix it. if possible, change the driver to be general code and not uses that kind of definitions. i understand you want to make it as fast as possible, but what is the point if it doesn't work. but if it is any help, the Arduino has many big problems with C++. the biggest i have encountered is the volatile type. in C++ version 20 and later, they have removed volatile type, or deprecated it, because it has conflict with some other types. woo hoo ! it is suppose to get better, but it gets shitttier!! this is what it is! it does compile it, but i have seen it in some of my codes that it causes reset of the core. something like this! but in your code, since it is going low level, you cannot remove volatile type. but you should use atomic types instead. #include <atomic> but i had problems with that too! go figure! and as another happy thing, Arduino can not even use pure "C" either! it only can use C++ . its that good! i have tried it, it doesn't work! so, please don't slap Closed on it.

[Robecq]

So I think I have (hopefully solved) my Guru meditation panic error. I run into the error when trying to connect a tft display to a esp32 /esp32 s3 wroom camera dev board and as mentioned above relates to how PSRAM is allocated/ SPI drivers. Specifically my issue occurs when the camera capture fails and returns NULL to the frame buffer causing the esp to crash. Note this only happens to me when using PSRAM. The fix for my code was to skip if the fb returns NULL

camera_fb_t* fb = capture(); if (fb == NULL) { Serial.println("Camera capture failed, skipping this frame."); delay(100); return; // Skip this iteration }

N.B I am not much more than a tourist here on github and coding in general, so please excuse me if make a faux pas or state something oblivious. I'm joining in here as I have been trying to solve my guru meditation for 3 weeks.

cheers :-)