ESP32-WROVER: panic in rg_gui_init #25
Comments
That SPI error is expected and can be ignored. It is possible to use two SPI peripherals but it can conflict with I2S's and SPIRAM's DMA and GPIO. If you're designing your own device you can have a look at using SDMMC instead. |
|
Thanks for looking up the backtrace. I don't know why esp-idf itself would crash. My best guess would be a SPIRAM issue. You can try commenting line 854 in rg_system.c (the one with that sets MALLOC_CAP_SPIRAM) to see if it goes through. You can also make sure SPIRAM is initialized, add that block towards the beginning of rg_system_init: multi_heap_info_t heap_info = {0};
heap_caps_get_info(&heap_info, MALLOC_CAP_INTERNAL|MALLOC_CAP_8BIT);
RG_LOGI("Internal memory: free=%d, total=%d\n", heap_info.total_free_bytes, heap_info.total_free_bytes + heap_info.total_allocated_bytes);
heap_caps_get_info(&heap_info, MALLOC_CAP_SPIRAM|MALLOC_CAP_8BIT);
RG_LOGI("External memory: free=%d, total=%d\n", heap_info.total_free_bytes, heap_info.total_free_bytes + heap_info.total_allocated_bytes);Do you know if the esp-idf bundled for arduino is patched by them? |
|
Hi @ducalex, Thanks for checking in! ========================================================
launcher 1.33-12-g30f929d0-dirty (Aug 27 2022 20:55:07)
built for: ODROID-GO. aud=0 disp=0 pad=0 sd=0 cfg=0
========================================================
[info] rg_system_init: Welcome! Reset reason: 4
[info] rg_system_init: Internal memory: free=253295, total=307383
[info] rg_system_init: External memory: free=4192151, total=4192151It looks like we have 4MB of PSRAM, which is good, I guess? I'd like to run only nofrendo + launcher. After commenting the line 854, it went through. What does it mean to be honest? Is the application supposed to work now? Log output: I can see the blank screen now, so I suppose it's a moment to figure out what's wrong with the LCD driver logic (ILI9341). |
|
Interesting, it fails few seconds later. It seems to be an issue with SPIRAM too: |
|
Yeah 4MB is what we'd expect. I'm not sure it's a SPIRAM issue per se but something seems to be corrupting the heap table? Because it seems to crash when we're just requesting info about it... That's usually caused by a stack overflow. You can try ediitng
After that you'll have to run I will do some testing with esp-idf 4.4.1 on my side as well. I always make sure that retro-go builds with esp-idf 4.0 - 4.4 but I only actually run the 4.1 builds. |
Unfortunately, I didn't reveal any more details.
Maybe I should downgrade the IDF to 4.1 or upgrade to 4.4.2? Anyway, let me know if I can help with bug chasing. I will continue with my investigation. |
|
I've tested esp-idf 4.4.1 compiling retro-go for target odroid-go and it boots correctly on a bare esp32-wrover module (as far as I can tell, I don't have a compatible LCD to see). It also boots and runs correctly on the odroid-go handheld. But I don't know if your sdk was modified for arduino (at least from your snippet you seem to be using the one provided by arduino-esp32). Can you tell me what changes you've made to retro-go (if any) and what commands you use to compile and run? |
Oh, it's just a random location. As most of my projects are Arduino related, I unpacked and installed this one too. Speaking of IDF v4.4.1 - git: 1329b19fe494500aeb79d19b27cfd99b40c37aec Git diff:
Commands: |
|
The first problem I see is that you use GPIO16 and 17 but on the WROVER they are used by PSRAM¹ (I don't think they are even exposed, so this is probably a typo in your code?). The second possible problem is that RG_GPIO_LCD_HOST and RG_GPIO_SDSPI_HOST are set to the same host but different pins. This can't work. One of them should be set to SPI3_HOST. (But again, using SPI3_HOST may conflict with PSRAM). ¹ https://www.espressif.com/sites/default/files/documentation/esp32-wrover_datasheet_en.pdf pages 14 and 19 |
Yes, it's my bad. Found by trials and already corrected it (uncommitted). Thanks for the explanation.
The reason why I started experimenting with this is that I want to keep the LCD on HSPI, but SD card on VSPI. I don't know if it's possible here. PS. I'm still learning the ESP platform, so please don't shoot for making rookie mistakes... |
|
If I may suggest maybe you can try getting it to work with the original pinout first, and then try moving peripherals around.
Of course, I'm sorry if I came across as rude that wasn't my intention at all! I guess it may be worth trying accessing the PSRAM before doing anything with SPI or GPIOs. Like putting this at the top of char *ptr = heap_caps_malloc(0x100000, MALLOC_CAP_SPIRAM|MALLOC_CAP_8BIT);
printf("allocated 1M at %p\n", ptr);
strcpy(ptr, "Hello World!");
printf("written '%s' to %p\n", ptr, ptr);
// then for good measure let's try a calloc, which is what rg_alloc does.
char *ptr2 = heap_caps_calloc(1, 0x100000, MALLOC_CAP_SPIRAM|MALLOC_CAP_8BIT);
printf("allocated another 1M at %p\n", ptr);BTW I see you've changed the shebang to use python3 in rg_tool.py. That is a good change, rg_tool.py stopped being python2 friendly very long ago and I know many OS do not even have an executable named |
I really appreciate all your efforts to help me. Thank you! The reason why I modified the pinout is to separate buses. My SD card reader seems to be a bit chatty, so it's safer to connect it to a separate bus. Unfortunately with this pinout, IDF complains about DMA channel: I'm wondering if it's possible to disable the DMA for the SD card bus (SPI3). EDIT: it looks like I can get rid of that error (at least temporarily), if I assign two different DMA channels (1 & 2). LCD is white so far, researching... |
|
Success!! I managed to run NES emulator. I noticed one bug, not sure if we should discuss it in this thread or another. After a few seconds of gaming, the screen colors become inverted, and after a minute of play the screen becomes white. Is it a known issue? It's a Chinese no-name TFT LCD on ILI9341. rg_display.c
|
I absolutely understand, I've spent countless hours working around the limitations of having to share a bus and in my own designs I use SDMMC instead. I was only suggesting sticking to the untouched config first to help narrow down the problem. Glad to see it now (mostly) works! Can you sum up the resolution? Can you think of code changes I could make that would have helped you find the issue faster? For the LCD it is not a known issue but I can think of a few ways this could happen. If you open a new issue please include your new pinout :) . |
Many times I've had to ask people to inject code to get that info when narrowing down problems. It should have been part of the log all along, really!
Keep in mind that I didn't have prior experience with ESP32, so it's highly likely one the reasons why it took me longer. I had to read a bit about the SPI driver and VFS.
When you're using 2 SPI buses (as I do), the
The option that worked in my case was: host_config.max_freq_khz = SDMMC_FREQ_PROBING
Once I commented this line in I don't know what's wrong with this particular alloc property. As you can see, you gave me valuable hints and I really appreciate it. Thanks! I still have components to enable (audio, joysticks) and I'm excited about it :) Regarding the LCD issue, I will open another issue and provide relevant data. |
|
Thank you for the feedback :) I was actually breaking
Yeah esp32 is picky with SD Card, especially when the circuit isn't perfect. I have now added a fallback to probing speed in 9eebd48 . Maybe this should be tunable in the target file too, though. |
Describe the bug
It looks like the application panics when the launcher tries to prepare the draw buffer.
To Reproduce
I used ESP32-WROVER with IDF SDK v4.4.1.
Full stacktrace
Side question: I'm also concerned about this line:
I'd like to use separate SPI buses for SD card and LCD, but I suppose it's impossible due to lack of DMA available on SPI3?
The text was updated successfully, but these errors were encountered: