ESP32 Forum

TL;DR: We just released a *beta version* of esp-idf with support for external PSRAM. If you hook up the correct chip, it should give you 4MiB more RAM than a plain ESP32 has.

So, it's been in the datasheet forever, some people actually were lucky enough to receive some chips and it some companies already use it in private: the ESP32 has support for 4MiB of external RAM which it can use in (almost) the same way as the internal RAM. Today, we have released the toolchain and SDK you need to make use of it.

For this to work, you need an ESP32-module or board that has a V1 ESP32 and uses 1.8V flash. (The ESP32-D2WD with internal memory may work, but it's untested as of now.) You also need an ESP-PSRAM32 chip, as that's the only external memory chip supported for now. The connections that are needed essentially are: wire the RAM chip in parallel with the existing flash chip except for CLK and CS. Route CLK to GPIO17 and CS to GPIO16 instead. Alternatively, get yourself an ESP32-WROVER module; that essentially is similar to an ESP32-WROOM module but with PSRAM built-in.

You can download the beta esp-idf and the toolchain from the usual spots (https://github.com/espressif/esp-idf and https://github.com/espressif/crosstool-NG) but be sure to switch to the psram-compatible branches. For esp-idf, the branch is called 'feature/psram_malloc', for the toolchain it is called 'xtensa-1.22.x-ext_ram_patch'. Note that there are no binaries available for the toolchain, you will need to build it from source. For the different OSses, this is documented here: Linux Mac (Sorry, no Windows support for this yet.). Note: In order to get the psram version, in the instructions at the 'git clone' command, replace 'xtensa-1.22.x' with 'xtensa-1.22.x-ext_ram_patch'. For esp-idf, just clone esp-idf as usual, then do 'git checkout feature/psram_malloc'.

FAQ: (Well, questions no one asked yet but which we think you may want to ask)
How do we get the PSRAM chips / Wrover modules?
At the moment, the only place you can get them is sales@espressif.com. Be aware that due to the beta status of this thing, they do not have too many items in stock, so do not be surprised it you cannot get one immediately.

Why did this take so long?
As you may know, the V0 ESP32 had a bug in it that stopped psram from working at all. V1 mostly solved this bug, but not entirely: some instruction sequences, sometimes only in combination with an interrupt at a very specific time, could cause data corruption. We spent a fair amount of time characterizing and tracing back the origin of this bug before formulating a feasible workaround. This is also why you need to grab a new toolchain: it doesn't emit the instruction sequences that have a potential for errors.

Workaround? What consequences does this have?
For a normal user, mostly that all code will run somewhat slower. We haven't characterized the slowdown yet, but it's depending on the application and we estimate it in the range of 10-20%.

Is there documentation for all this?
We'll be uploading an updated ECO with the PSRAM cache details shortly. Datasheets for the ESP

Can I read more about the esp-idf implementation of psram support?
Sure! In the feature/psram_malloc branch, you can find docs/api-guides/external-ram.rst giving some more info.

What if I find a bug?
Feel free to post those either here if you're not entirely sure if it's a bug, or on Github as an esp-idf issue if you are. Be sure to mention PSRAM somewhere in the title if you post it on Github so we know it's about that specific branch.

I have another question
Feel free to ask it in this thread.

This is really great! Sad about needing all the workarounds, but still great.

hazard when certain sequences of machine instructions operate on external memory locations

If most of the application code doesn't access external memory (or rather any heap memory capable of being in external memory I guess), that code will not be impacted by the performance reduction, only code that uses external memory?

Possible to use 64mbit chip and access the additional unmapped space using spi_ram_read/write type commands?

Thank you Jeroen for your effort on it!

perfect timing! txs! now we try to build it.

like WiFive i have the same Question:
"Possible to use 64mbit chip and access the additional unmapped space using spi_ram_read/write type commands?"

does a virtual wear leveling drive on the rest would be possible? ( XMDISK likewise )

best wishes
rudi

Unfortunately, the compiler can't see with 100% certainty which routines access PSRAM and which don't at compile time, so normally the workaround is enabled globally. If you use PSRAM in such a way that its use is limited to a subset of your program, you can use the workaround flag on only those C-files or components.

In theory it's possible with an 8MiB device to use the excess 4MiB as a normal peripheral, however we have not implemented anything like this (also because we only have 4MiB devices here.)

Rudi: Why wear leveling? It's RAM, it doesn't need wear leveling.

ESP_Sprite wrote:
Rudi: Why wear leveling? It's RAM, it doesn't need wear leveling.

that is the answere i needed, now i understand this better - thank you.

one thing Jeroen is not 100 % clear to me - but i think it is an easy thing:
CLK and CS pins are outside from the VDD_SDIO Domain ( 1.8 V )
does they not have high level 3.3V ? this was my confuse in this thing Jeroen honest.
thank you!

best wishes
rudi


edit:

you need an ESP32-module or board that has a V1 ESP32

the wrover with mounted pSRAM, that was delivered last weeks - and 502016 product date ID have -
they all V0 ESP32 ? - this mean, that we can not use the mounted pSRAM on it?

they do not have too many items in stock,

are this spoken Wrover / ESP32 SoC Chips V1?

do you know the productions date ID on the ESP32-D0WD
that are V1 and can you write here the date ID?
thank you -

CLK and CS are GPIO16 and 17, which as far as I can see (http://www.espressif.com/sites/default/ ... ist_en.pdf page 5) are in the VSDIO domain.

ESP_Sprite wrote:CLK and CS are GPIO16 and 17, which as far as I can see (http://www.espressif.com/sites/default/ ... ist_en.pdf page 5) are in the VSDIO domain.

ok Jeroen, txs - i have parallel edit my post in the meantime your wrote - can you please say to the edit version some details - txs.

ESP_Sprite wrote:Unfortunately, the compiler can't see with 100% certainty which routines access PSRAM and which don't at compile time, so normally the workaround is enabled globally. If you use PSRAM in such a way that its use is limited to a subset of your program, you can use the workaround flag on only those C-files or components.

Makes sense. What about ISRs? Any other "best practices" advice?

rudi ;-) wrote:wrover with mounted pSRAM, that was delivered last weeks - and 502016 product date ID have -
they all V0 ESP32 ? - this mean, that we can not use the mounted pSRAM on it?

Possible they made small batch rev1 in 502016. Hard to believe they would send nonfunctional psram wrover to customer. Not sure if efuse revision check for rev1 would be valid in test batch.

WiFive wrote:

rudi ;-) wrote:wrover with mounted pSRAM, that was delivered last weeks - and 502016 product date ID have -
they all V0 ESP32 ? - this mean, that we can not use the mounted pSRAM on it?

Possible they made small batch rev1 in 502016. Hard to believe they would send nonfunctional psram wrover to customer. Not sure if efuse revision check for rev1 would be valid in test batch.

edit: perhabs this was not knowed to this time stamp in dez 2016 that this is nonfunctional psram modul?
i got the wrovers in may 2017 btw. and would update the wrover kit with this too,
but if they not Rev1 - this makes no sense to update wrover kit..


txs WiFive - the check with new hello world from examples show Rev0
but ok - could be that this is not valid.

just in time toolchain comes to final steps - ( 138 min ) "install final gcc compiler "
then i can test this ( not sure next hour but today - was long night )
btw: we have in this toolchain then "only gcc compiler - no g++" right?

txs WiFive!
best wishes
rudi