ESP32 Core 1 panic'ed (StoreProhibited). Exception was unhandled when tft.init() is executed. #3332
Comments
|
Corrected Debug Output in zip file. (elements dropped during the copy) Regressed to 2.0.16 ESP-ROM:esp32s3-20210327 Hello! ESP32-S3-WROOM SPI PINSMOSI: 11 Start Channel ScanningGuru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled. Core 1 register dump: Backtrace: 0x42003e9a:0x3fcebda0 0x42003f69:0x3fcebdd0 0x42002b98:0x3fcebdf0 0x420091ca:0x3fcebe20 |
|
Having a similar issue on a completely different hardware setup (Waveshare round LCD with integrated ESP32S3). Using platformio, this happened once the platform 6.7.0 was updated for espressif32. For now to workaround I am locking the platform version to 6.6.0 in my platformio.ini using "platform = espressif32@6.6.0" |
|
Looks like this is a duplicate of: |
|
@elgerg Yup, I would tend to agree... |
|
Yes, I agree with the assessment.... I did not read far enough.... my oversight! |
|
I have the same Issue with ESP32-S3 and the ILI9341 Core 1 register dump: Backtrace: 0x42002c3c:0x3fcebbd0 0x42002d11:0x3fcebc00 0x42001ace:0x3fcebc20 0x4200635a:0x3fcebc50 ELF file SHA256: 9ad77e336525fede Rebooting... |
|
I have since regressed my versions to TFT_eSPI to 2.5.0 an ESP32 to 2.015 and everything is working well. My projects are working as expected . This is true for my ESP32-S3 and ESP32-C3 designs. My ESP32-S3 code test configuration, shown below, now displays the information very nicely. At this point in time, I am ok with the current versions, but still want to work with the current releases.
|
|
with this platformIO ; change microcontroller framework = arduino lib_deps = Wire it works now with the ESP32-S3 |
|
I have the same problem .
end_tft_write();
} // end of: if just _booted
Serial.printf("!!!!here!!!\n");
// Toggle RST low to reset
#ifdef TFT_RST
#if !defined(RP2040_PIO_INTERFACE)
// Set to output once again in case MISO is used for TFT_RST
if (TFT_RST >= 0) {
Serial.printf("!!!!5555here!!!\n");
pinMode(TFT_RST, OUTPUT);
}
#endif
if (TFT_RST >= 0) {
Serial.printf("!!!!6666here!!!\n");
writecommand(0x00); // Put SPI bus in known state for TFT with CS tied low
Serial.printf("!!!!7777here!!!\n");
digitalWrite(TFT_RST, HIGH);
Serial.printf("!!!!8888here!!!\n");
delay(5);
digitalWrite(TFT_RST, LOW);
delay(20);
digitalWrite(TFT_RST, HIGH);
}
else writecommand(TFT_SWRST); // Software reset
#else
writecommand(TFT_SWRST); // Software reset
#endiflog is bellows: platform.ini as bellows: |
|
same problem here. Here's my sketch: TFT_eSPI tft = TFT_eSPI(); void setup() SPI.begin(); tft.begin(); void loop() as soon as I uncomment the line tft.begin(); I get: *** Program: C:\Users\chris\Dropbox\Arduino\Arduino Project Code\CAN\SportChrono FOLDER\XIAO_TFT\XIAO_TFT.ino Core 0 register dump: |
|
OK, quick update: |
|
one more update: It also works with esp 2.0.17 (which is the final version of 2.0.x) |
|
final (?) update:
|
|
For me, last working core is: 2.0.14 |
|
I have spent days trying to get to this point where init doesn't crash. ESP core version 2.0.14 is working for me with TFT_eSPI 2.5.43. Setup file: #define TFT_CS 10 // Orange 10 or 34 (FSPI CS0) // Use pins in range 0-31 //#define TOUCH_CS 16 // Optional for touch screen #define LOAD_GLCD #define SMOOTH_FONT // FSPI (or VSPI) port (SPI2) used unless following defined. HSPI port is (SPI3) on S3. //#define SPI_FREQUENCY 27000000 #define SPI_READ_FREQUENCY 6000000 // 6 MHz is the maximum SPI read speed for the ST7789V |
|
2.0.14 works for me. Thanks |
|
After much trial and error, I was able to avoid the panic reboot from
I don't know how or why...I'm pretty sure I reverted all the other hacks that were tested in TFT_eSPI_ESP32_S3.h |
|
I just tried with esp32 3.0.2. Result |
That fixed it for me! Thanks! |
|
It works !!!!!!! Thank you very much... |
It also works for me! Thank you so much! |
|
how does that work when every line is commented out? |
I copy the board settings from the library headers into the project .ino file in case my configuration gets wiped out in a library update. I copied the consolidated settings from my .ino that happened to be commented out. The difference that avoids the panic is |
Just came to say THANK YOU for this! I spent hours yesterday fighting with this issue... which is now fixed. Hooray! |
|
I also had the problem and the #define USE_HSPI_PORT was the root cause. Not sure why suddenly it's required? perhaps a library investigation should happen? |
It works! Addition of #define USE_HSPI_PORT in user setup. ILI9341 LCD 2.4inch Thank You !!! |
Adding DUSE_HSPI_PORT=1 build flag to my platformio.ini avoids the panic reboot in my ESP32-S3. Anyway, I need to use the faster SPI port to get the maximum performance out of the display. |
|
Hello, I have the same problem . I put some serial print in the code and I found where the guru panic appears. I use VScode and Platform IO. The problem don't exist if I use a ESP32 wroom but it appears with ESP32-S3 type the problem is in the function TFT_eSPI::begin_tft_write(void) at the line SET_BUS_WRITE_MODE; my SPI pinout Log in serial monitor Have you some news since September? Regards, |
The issue that I am encountering is that a "Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled." just prior to executing the tft.init() function. This issue appears to be only graphics bases since I can execute this sketch with only Serial.println("..."); calls. I can use the Adafruit_GFX.h with the Adafruit_ST7789.h driver to do a test on a GFX application.
During an update something changed and I am at a loss to determine the root cause. Wiring is correct ( I have checked it many times).
See the following attached files for additional information you require:
User_Setup.zip
Sketch:
WIFI_Channel_List.zip
TFT ; ST7789 IC 1.9 Inch ips Full View TFT Display LCD Color Module SPI Serial Port HD 170x320 MSP430 and C51 Programs
I have only one of these displays....
DEBUG Output:
Debug Output.zip
Plus further information as appropriate to the problem:
Thanks, John Taylor
I can be reached at taylorjw.nc@att.net
The text was updated successfully, but these errors were encountered: