ESP32-CX external PSRAM SUPPORT (IDFGH-9872)

[CrowdedFuzzball]

Hello!

I didn't sure that it is esp-idf question, but seems like this is related to software architecture.
I can't find any information about external SPIRAM support on ESP32-CX SoCs family.

All data sheets that i see missed this information.
This can mean 2 options:

1. There no limitations to use external PSRAM in RISC-V processors
2. There no chance to use external PSRAM in whole ESP32-CX family.

Could you please help with understand this things?
Does ESP32-CX (for example ESP32-C6) supports external SPIRAM?

Apologise if this question is not related to esp-idf

[igrr]

Hi @CrowdedFuzzball, the C-series chips (C2, C3, C6) do not have hardware support for PSRAM. This means that:

• It's not possible to map external PSRAM into the CPU address space, like it is on ESP32, ESP32-S2, ESP32-S3.
• It is still possible to access an SPI-connected PSRAM chip by software and read and write data at specific offsets. IDF doesn't provide such a driver, but it can be written on top of the "SPI master" driver. In this case, you can still use external RAM (whether PSRAM or conventional SPI-connected SRAM) but you can't "malloc" memory from PSRAM or place variables there. You would have to read and write data there by means of some function call.

---

A software-based approach to integrate PSRAM into the CPU address space is also theoretically possible:

• Set up RISC-V physical memory protection (PMP) such that reads and writes to a certain region of CPU address space are prohibited
• Write an exception handler which will catch attempts to read and write this region
• In the exception handler, decode the address and perform access to PSRAM over SPI, in software
• If this was a read access, store the data back into the CPU register
• Move the exception program counter to the next instruction and exit from the exception

This concept was implemented a while ago on the venerable ESP8266 (which also has no hardware PSRAM support) in esp8266/Arduino#6994.

The performance of such way to access PSRAM is most likely not great: entering and exiting the exception handler is expensive, there is no caching, therefore each variable access has to be converted into an SPI transaction. However for fun and learning this could be implemented.

We do consider this fun approach to be out of scope of IDF project, and will support PSRAM only on chips which have hardware support for it.

[CrowdedFuzzball]

@igrr Thank you very much for such clear explanation

A software-based approach to integrate PSRAM into the CPU address space is also theoretically possible:
Set up RISC-V physical memory protection (PMP) such that reads and writes to a certain region of CPU address space are prohibited
Write an exception handler which will catch attempts to read and write this region
In the exception handler, decode the address and perform access to PSRAM over SPI, in software
If this was a read access, store the data back into the CPU register
Move the exception program counter to the next instruction and exit from the exception

I understand that it is some kind of not-good workaround.
But could you please explain what is hardware solution used in ESP32 series with PSRAM support?

Am i right that if we use PSRAM hardware support it should be a full-fledged hardware processing of memory commands over the spi protocol + some kind of caching?

[igrr]

You are right, In ESP32, ESP32-S2 and ESP32-S3 there is a dedicated hardware block which is mapped into the CPU address space. It receives load and store requests from the CPU, performs address translation and caching, and services cache misses by sending SPI transactions to PSRAM.

It's roughly the same thing that is used for code execution from Flash, which is also cached and mapped into the CPU address space. The main difference is that Flash is mapped as read-only, while PSRAM supports both reads and writes. Hence the related hardware and the cache have to be more complex to support PSRAM.