Problem to run / build on esp32s3 about retro-go HOT 13 OPEN

That's an interesting crash, I'm not sure why the stack would overflow. But our stack is pretty small, maybe your version of esp-idf has more overhead or just the s3 i2c driver in general?

The task is created in rg_input.c, look for the rg_task_create call. There you can adjust the stack size (replace 2 * 1024 by 4 * 1024 or even more).

If other tasks cause overflow you can search for other calls to rg_task_create and patch them. If the main task causes an overflow, you can adjust that stack in (menuconfig) → Component config → Common ESP-related. Retro-Go expects 8192. Default is smaller, I think.

So the problems seems being in the final image generated, not in the each project build

Yeah it's odd, I guess the format changed for the S3 or we're doing something stupid. I'll have to do some testing later!

In the mean time you could try creating a partition table yourself. Once the table flashed, rg_tool.py should be fully functional. You'll be able to run rg_tool.py flash to flash all apps.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-guides/partition-tables.html

The partitions retro-go expects are listed in rg_config.py and your CSV file would look as follows (untested):

# Name,   Type, SubType,  Offset,   Size,  Flags
nvs,      data, nvs,      0x9000,  0x4000
otadata,  data, ota,      0xd000,  0x2000
phy_init, data, phy,      0xf000,  0x1000
launcher, app, ota_0, 0x10000, 917504
retro-core, app, ota_1, , 786432
smsplusgx-go, app, ota_2, , 524288
snes9x-go, app, ota_3, , 655360
prboom-go, app, ota_4, , 917504
gwenesis, app, ota_5, , 1114112

Note: the sizes listed in rg_config.py will likely be too small, S3 builds are bigger, plus your menuconfig isn't as optimized for size than our sdkconfig. I added 128K to all partitions in the above example, but if you have enough flash, I suggest just making all partitions 1M for simplicity!

from retro-go.

Just some additional information:

I have seen the Open PR on this project about the S3 and an other issue talking about S3:
#95

I've tryed your procedure and it compiles the only difference is that I ran:

PROJECT_VER=develop python rg_tool.py --target=esplay-s3 --no-networking build-img launcher

Instead of

rg_tool.py --target=esplay-s3 --no-networking launcher

So I had some warning but, as you said, the compilation ends successfully.

But when I upload the img to the S3, I'm facing the same problem of "invalid header...."

My S3 is a 16m flash and 8m of SPIRAM can it comes from there?

PS: I've tryed to build the code from the PR with idf-v4.4 and I was able to compile, but after uploading the img file, the result is the same

from retro-go.

The missing #include is fixed in the dev branch and I suggest you work on the dev branch because that's where further S3 fixes will go!

One thing you could try is to just build the launcher alone like you would any other esp-idf project, bypass the entire rg_tool and image creation process.

1. Go to the launcher folder
2. run rm -rf sdkconfig* build
3. run IDF_TARGET=esp32s3
4. run RG_BUILD_TARGET=ESPLAY_S3
5. run idf menuconfig and select the options needed by your board
6. run idf app flash monitor

By the way did retro-go had been tested qui target=esplay-s3 ? Because with what is missing in config.h file I cannot figure how it could work. :-)

I think the author did successfully run it on his device but never finished the PR. And lots of change were made to both retro-go and esp-idf in the mean time, so I have no idea if current runs on S3 or not.

Could you advice me something? I think there may be a problem with the baseS3.sdkconfig , I suppose it was generated with the idf 4.3 and I'm using 4.4 to build...

It was likely generated with 4.4 or 5.0, as 4.3 never supported the S3.

from retro-go.

Hello! Thank you,

So now everything seems booting well

So it crashes because of not correctly configured pins, etc etc (it's full ok for this part, I'll debug it later).
But the esp32s3 boots correctly!

in the idf menuconfig I left nearly everything by default, just I had to enable PSRAM, and setup it to OCTAL Mode.

how could I go ahead to build something that the launcher would be able to launch ;-) ?

Thank youuu

from retro-go.

Little additional information (quite obvious but may be usefull):

I tryed to build the launcher with rg-tool as usual (cleaning all before)
Then I enter in launcher folder and do idf.py flash. In this conditions the esp do not restarts.

So the problems seems being in the final image generated, not in the each project build

from retro-go.

Hello! First of all thank you very much for all this advices.

On my side I finaly found the problem of the final img file. After a bunch of tests I noticed that when I flash with an ESP32 the bootloader is written on 0x1000 adress. And in tg_tool on line 170 it writes the bootloader with 0x1000 offset in image_data.

But on an ESP32s3 when I flash it the bootloader is loaded on 0x0. So I tryed to put 0x0 instead of 0x1000 and it works fine!

for now I made a quick fix if rg_tool.py

Also to get the compilation works I had to add the set of the IDF_TARGET env var

About the crash due tu overflow I don't really pay intention to it, because have no I2C device connected, so I supposed the error may come from it. And I'm not planning to use it. I have just configured the ODROID-GO driver for the controls and it work pretty fine.

Next steps are to plug a SD card adapter and to map it to a separate SPI port. (Because my LCD do not have a CS pin, I have to use a SPI just for it)

Then I'll try to connect a I2S DAC... Suprisly the esp32s3 has no integrated DAC.

Once every thing is working, I plan to make a PR here,
I created a new target, and I'll document with schematics for the hardware.

What do you think about it?

from retro-go.

But on an ESP32s3 when I flash it the bootloader is loaded on 0x0. So I tryed to put 0x0 instead of 0x1000 and it works fine!

Thanks for the info about the image format! I'll push a fix in a few days, it will likely be an environment variable set in env.py like we have for the .fw format. Or maybe I'll check IDF_TARGET. Not sure yet.

Also to get the compilation works I had to add the set of the IDF_TARGET env var

Each target has a env.py so you can put your environment variables there without changing rg_tool.py. Same for your sdkconfig file. Once you're satisfied with your menuconfig changes, you should take that sdkconfig file and put it in the target, so that all apps use it.

Next steps are to plug a SD card adapter and to map it to a separate SPI port.

SDMMC 1-line is faster than SPI and uses the same amount of pins (or less), I would use that if I were you!

https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/peripherals/sdmmc_host.html

(retro-go already has support for it, check how mrgc-g32 or esplay-s3 do it in their config.h)

What do you think about it?

Sure, I'm always happy to accept new targets :). It would be nice to have a known working S3 target.

from retro-go.

Hello! Thank you very much for all your good and helpfull advices,

I finaly get nearly everything works. Remaining to test I2S Dac, not yet plugged, but the rest works fine.

For thoses who will need to make work be carefull with pins assignements. Somes are reserved and cannot be used as we need on Esp32s3. So my advice would be to make a kind of grid to choose the right pins, for instance I made this:

Also when something doesn't work, try building and uploading a minimal program for the Esp32s3. I had a lot of troubles to make work the SDSPI, so I used the idf example for the sdspi to debug, and find the right pinout.

Also be very very carrefull with the power supply. USB from computer may not be the best power suply. My SD card had some troubles and crashed with strange codes (263) when writting or erasing blocks. I tryed with the USB of an other computer and it worked fine.

Other point: the sdkconfig file had to be updated mainly for the configuration of SPIRAM, I join to this comment my sdkconfig for the esp32s3 (it was not generated but, its @ducalex version updated)
sdkconfig.txt

@ducalex As I said, I will clean up a little all my modifications, and I will make a little PR =). I just want to finish all tests and play a litte with this stuff. =)

from retro-go.

Very last question before closing this issue,

I don't think it has any relation with the esp32s3 but maybe you have a quick answer for my troubles:

Around sprites pixels doesn't desapear

I have some little screen glitches,

I'm using RG_SCREEN_TYPE == 0 and I updated the Memory access param

From
ILI9341_CMD(0x36, {(0x20|0x80|0x08)});
to
ILI9341_CMD(0x36, {(0x60|0x08)});

I made it in order to rotate screen by 180 degres (up down)

But with this modification I observe some pixels that doesn't disapeard around sprites.

Maybe the way I flipped upside down the screen isn't the right way to do so... Do you have any advices for this point? I suppose that I'm doing something wrong, because with your original configuration, there is no this kind of problem.

In launcher screen overflows on right

Also in the launcher there kind of margin problem the image starts with some pixels from the right side:

Do you know if there kind of configuration to fix it?

In launcher background blinking (like low refresh rate)

And very last point, I observe a kind of background blinking in launcher. (like a little to low refresh rate) It's not really a problem, but I wanted to know if somebody has repported this point. I suppose it happens on other devices too.

from retro-go.

But with this modification I observe some pixels that doesn't disapeard around sprites.

I'm not sure. It certainly could be a missing/incorrect command in your init sequence. But in the past we've had similar glitches caused by various other reasons that you could check:

1. SPI gpio conflict
2. SPI connectivity (bad contact, interference, especially on breadboards)
3. Buggy bilinear filtering
4. Buggy partial update mechanism

For 2 you can play with RG_SCREEN_SPEED in your target's config.h, try a lower or higher speed like SPI_MASTER_FREQ_80M, SPI_MASTER_FREQ_40M, SPI_MASTER_FREQ_20M

For 3 and 4 you can disable these in the options menu. If it's not currently accessible to you, you can set them manually in rg_display_init in rg_display.c. For example replace .update_mode = rg_settings_get_number(NS_APP, SETTING_UPDATE, RG_DISPLAY_UPDATE_PARTIAL), with .update_mode = RG_DISPLAY_UPDATE_FULL,

And very last point, I observe a kind of background blinking in launcher. (like a little to low refresh rate) It's not really a problem, but I wanted to know if somebody has repported this point. I suppose it happens on other devices too.

I don't notice any flicker with the devices I have, and I don't think anyone reported that issue to me! I know the ILI9341 has a command to control the refresh rate, maybe yours isn't set correctly? It's described on page 155 of the datasheet: https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf .

Also I think in the thread about running without PSRAM I told you to remove the line rg_gui_set_buffered(true); in launcher/.../gui.c. Make sure that change has been reverted (if you tried it) because it will cause significant flicker!

from retro-go.

Also is your screen resolution 320x240? I've never tried higher res screens, it could be part of the issue.

PS: Please base your PR on the dev branch please because I did some changes to accommodate the S3 better that aren't in master yet (moved sdkconfig to the target folder, moved the LCD init sequence to the target config file, the rg_tool.py changes, etc).

Edit: Actually I merged the relevant changes to master, you can base on that if you prefer!

from retro-go.

Hello, thank you again for your answers

I made my PR and tested all the stuff with your dev branch. And once fixed the issue I repported here #99 the screen seems working much better.

I havent yet found what change in your code makes it work better but glitches around the stripes has desapeared. The problem with the pixels overflowing from right side to the begining of the left side has desapeared also.

An other improvement I noticed: Before when I enter from launcher in a game, and when I exit from game to main menu, the screen had some buggy frames. Now it passes to black between this changes. it's very clean.

For information I'm using a 320x240 screen.

The only remaining default is this kind of blinking screen in launcher. But it's not a big deal. I haven't yet played with the spi speeds. I quickly looked at the ili9341 datasheet, but it will take a while to understand everything.

Also just for information I had this line rg_gui_set_buffered(true); correctly setted

from retro-go.