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: LinuxMac (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.

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?

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.)

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 wishesrudi

edit:

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

sales_wrover_may_2017.jpg (168.95 KiB) Viewed 6298 times

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 -

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.

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 Rev0but 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?

Who is online

About Us

Espressif Systems is a fabless semiconductor company providing cutting-edge low power WiFi SoCs and wireless solutions for wireless communications and Internet of Things applications. ESP8266EX and ESP32 are some of our products.