S3 OPI PSRAM (fallback to QSPI possible)?

[Jason2866]

Is there a possibility to use OPI PSRAM in QSPI mode?
With the latest changes it is possible to select PSRAM mode in Platformio.
We get now OPI PSRAM working. Great! But we did not managed to enable PSRAM (OPI chip)
in mode QSPI. Boot loops. Is this not possible? This would be a pitty since autodetection of PSRAM (working great for ESP32 and ESP32-S2) is now not possible for all MCUs.
At the moment we can provide one binary for every chip variant and it enables PSRAM when found.

[me-no-dev]

Currently Arduino starts PSRAM if selected only in QSPI mode. In OPI mode, PSRAM is started by IDF before it get's to Arduino. You can not have universal binary for all chips anymore. You need to select the proper mode for BOTH Flash and PSRAM or the chip will not boot.

• qspi_qspi for chips with QSPI Flash and QSPI PSRAM (or no PSRAM or QSPI Flash and disabled PSRAM)
• opi_qspi same as above but with OPI Flash
• qspi_opi for modules with QSPI Flash and enabled OPI PSRAM
• opi_opi same as above but with OPI Flash

[richcj10]

Is this done with board_build flags?

[ark02]

I believe this is set in memory_type however,

• qspi_qspi does not compile for me on 2.0.5. seems like qio_qspi works instead
  • On boards with QSPI Flash and no PSRAM, qio_qspi does not seem to help
• qspi_opi does not compile for me on 2.0.5. Seems like qio_opi works instead

[Jason2866]

@ark02 Yes, the naming has changed.

[Jason2866]

Thank you for the explanation! That is bitter, this circumstance will cause many problems and queries. I am sure many users do not know what type of flash and PSRAM their board has (and looking in actual boards.txt about PSRAM fix code many contributors dont know either when this is needed). Imho this will be no fun in the issue section...
Maybe a fallback solution can be found in IDF and Arduino?!

[me-no-dev]

it can not for now. There is some effort to make Flash at least detectable, but even that is not 100% certain. Then PSRAM is another issue all together. You need a binary compiled for your particular config (and the bootloader too)

[henrygab]

This is a bitter pill, indeed. Two questions:

1. Is there a technical reason that prevents a single binary from supporting either QSPI and OPI PSRAM, if the type is known (e.g., via efuse settings)?

2. Is it an option for Espressif to allocate 3 bits in the efuses to this purpose?

From Espressif's side, the allocation of efuse bits is all that is needed to enable projects to provide a single binary per family (e.g., one binary for each of ESP8266, ESP32, ESP32-C2, ESP32-S2, ESP32-S3). This would be much more helpful than a solution that forever will need to update a list of modules with their PSRAM settings....

As an example, I could imagine a solution similar to the flash's voltage(*) requirement:

• A first bit (anywhere) that indicates the PSRAM bus type setting is valid.
• Then two bits for storing the configured PSRAM bus type:

  2-Bit	Meaning
  11b	Undefined
  01b	QSPI
  10b	OPI
  00b	No PSRAM

Then, flashing tools and even firmware / bootloader would not need to try to probe the type... they could just read the eFuse bits. For example, a bootloader could implement the following logic:

1. detect if PSRAM settings are to be used, based on efuse values
2. if they are to be used, and they conflict with image in app partition, perform board-specific error handling (blinking lights, debug output, etc.)
3. else, use current behavior (allowing error / mismatch between chip and firmware)

On the positive note, once the bits are defined by Espressif, all customers can immediately start using them, and updating the efuses for any current devices.

(*) Thanks for using flash voltage efuse settings now!

**_THANK YOU_** for shipping modules of the newer families, such as ESP32-S3, with the flash voltage in the efuses by default. Having IO12 prevent boot (or burnout 1.8V flash) was a common "surprise" for hobbyists, and has caused much frustration over the years. **_THANK YOU_** ... this was a much-needed change!

---

[me-no-dev]

Honestly, such questions should be asked to the ESP-IDF team. Arduino just tries it's best to provide a simpler interface to IDF. There already is an efuse for Flash, but it was not burned on early chips/modules. More important: ESP-IDF itself is not geared towards such auto-detection. There are good reasons for that and the refactoring needed, if even possible, is quite a bit. You can search for the sdkconfig values in the IDF source and see what the differences are. If you think about it, on ESP32 you also can not be sure that you can run on all chips with single firmware, because some flash chips would not run in QIO mode or can not reach 80MHz.

With that said, I do agree that this new reality will bring us more issues and I do hope that things will improve.

[henrygab]

Honestly, such questions should be asked to the ESP-IDF team.

OK, I've opened espressif/esp-idf#9101 with the request.

[richcj10]

Well, with the only chips available at one time was the esp32-s3- wroom-2, this is going to be a headache. I am still having many issues with my hardware because of the opi setup. It works fine in arduino land but broken in platformIO. (WiFi issues, littlefs) Still hunting this down. Been on it for a month.