ESP32 PSRAM support

[rudi ;-)]

Huh, you're right - seems I skipped over pin 7. Thanks for noticing, will fix it as soon as I have time. Same with the code/documentation discrepancy - those should match up, will see which one is wrong.

I can't easily check the code now, but my guess is that WP and HOLD aren't mentioned anywhere in the PSRAM code because they're already set up correctly for the SPI flash. On a flash chip, in the right mode (quad I/O) they *are* actually used as data pins; it's just that quad I/O is a relatively new development, and seemingly the chip manufacturers still only use the old pin names. (See e.g. here, last sentence of 7.3 on page 8.)

hi jeroen,
only for the protocol
please add GND pin too


and btw,
ESP32 rev0 pSRAM - done!

@John Lee
sry - but i could not wait - now i have it manage by self.
we have events on june 6. and we want show on the education board the pSRAM
we are ready on one weekend - how long pycom have played? 1/2 year?
...
...
done on one weekend!
now its time to go few hours sleeping.
best wishes
rudi

psram_done.png (50.84 KiB) Viewed 15849 times

[rudi ;-)]

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

thank you Jeroen!

now after 42 h - pSRAM runs here on wrover with ESP32 rev0


cause have learn many things in datasheet and other by searching mistakes, studdy code and other...
..but I will never be able to give water you and ivan,
you are the best. worldwide!

hope espressif knows about your 1000 procent knowledge, this can nobody take from your head.

think we can go on here now too - hey - keep smile! i like you
@ivan and you too!

sory for the pressure making - but we all work better under pressure
i am too.

best wishes
rudi


before i forget:

You can download the beta esp-idf and the toolchain from the usual spots ......
...Note that there are no binaries available for the toolchain, you will need to build it from source. ....
(Sorry, no Windows support for this yet.)....

sry - only for the protocol,
i develop here under windows in eclipse neon3
and sure - linux too.



thanks for you smile

[rudi ;-)]

now playing with the modes
SPI PSRAM check on boot -> ok

we have now 4096 KiB in ESP32 rev0 available
now we go on to work with it.

hey guys - are you ok?

drum_roll_2.png (64.03 KiB) Viewed 15816 times

best wishes
rudi

[WiFive]

we have now 4096 KiB in ESP32 rev0 available

So how to trigger the bug on rev0?

[ESP_igrr]

Like this:
https://github.com/espressif/esp-idf/bl ... icon_bug.c

[rudi ;-)]

Like this:
https://github.com/espressif/esp-idf/bl ... icon_bug.c

ok ivan, will check it. ( we have on monday holiday here )
can you perhabs say, where the 16 byte are reserved,
i search just in time -

just one word:
i am happy now with this what here works and how it works -
now i try to combine it step by step with the application code
will see/test where and how the limits then are in rev0 / rev1

we have now 4096 KiB in ESP32 rev0 available

So how to trigger the bug on rev0?

what was done:
toolchain like jeroen described
one step more after check out future/psram_malloc, update libs

the boot check on 4096 was ok.
the demo/compare code was ok
the 1 MB MallocCaps works
the 2 MB MallocCaps works
the 3 MB MallocCaps works
on 4 MB MallocCaps i work just in time -
i look how much is reserved for something,
in menuconfig there are some parameter

i was gone simple steps,

final_check_reserved_16Byte.png (20.42 KiB) Viewed 15803 times

final i found out, there are 16 Byte reserved - or i do a mistake with my code:

Code: Select all

   uint8_t res = 16;
    // uint32_t
	char* buffer = pvPortMallocCaps((4*1024*1024)-res, MALLOC_CAP_SPIRAM);
        if (buffer==NULL) {
           printf("could not create SPIRAM Pointer\n");
        } else {
          printf("RAM init done\n");
          printf("reserved: %d\n", res);
          memset(buffer, 0x67, ((4*1024*1024)-res));
          buffer[((4*1024*1024)-res)-1] = '\0';
          printf("len of my PSRAM Buffer is: %u\n", (uint32_t)( (strlen (buffer) + 1) * sizeof(char)));
        }
        free(buffer);

for better see 4*1024*1024
i wrote not

Code: Select all

memset(buffer, 0x67, (4194304 -res));

best wishes
rudi

[ESP_Sprite]

The heap allocator needs a few bytes for internal housekeeping, yes.

[rudi ;-)]

The heap allocator needs a few bytes for internal housekeeping, yes.

txs, 4 word pointer, man in the middle ?

btw:
here is a small unofficial check file as firmware.bin to check
if you can't build toolchain/compile the firmware.

- revision
- embeddedFlash/extern Flash
- pSRAM / no pSRAM
- if pSRAM
--

Code: Select all

char* buffer = pvPortMallocCaps((4*1024*1024)-res, MALLOC_CAP_SPIRAM);

psramtest_0x0.bin.zip

(426.78 KiB) Downloaded 1145 times

rename the *.zip file to *.bin file and flash this to 0x0
example flash tool windows V 3.4.8

check_your_wrover_32.jpg (308.31 KiB) Viewed 15770 times

best wishes
rudi

[rudi ;-)]

Huh, you're right -..

now ESP32-D2WD

first,
in the actually ESP32 Datasheet ( side 17 ) we read:

datasheet_9_june_2017.jpg (31.29 KiB) Viewed 15645 times

esp32_datasheet_en_2017_june_9_V.1.5.pdf

Datasheet
V 1.5 2017 June 9

(1.12 MiB) Downloaded 832 times

can this be right?
why i ask:

in the datasheet stand too:

D2_eMbeddedFlash_externalSRAM.jpg (93.22 KiB) Viewed 15645 times

there is named, that GPIO16, GPIO17 is used for the eMbeddedFlash
there comes now confused question/thinking:

With regards to using D2WD with PSRAM: it is possible, as the extra CS and CLK signals to PSRAM are routed via the GPIO matrix. But depending on the pins chosen, it may not be possible to achieve 80MHz clock due to timing differences between various pads. 40MHz clock should still be possible.

- this two pins comes from the GPIO Pad and can not so fast (40) / ( 80 )
- the SD_DATA2 and SD_DATA3 are in VDD_SDIO ( VSDIO ) Domain and can fast but not used?

are the pins "named" swapped perhabs?
if not, in which mode is the eMbeddedFlash then run, there is only 2 DATA Pins, it looks then like not quad mode?

how we connect the external SRAM to the ESP32-D2WD in this steps of pin notes?
we have then no CLK and CS for external SRAM from the VDD_SDIO ( 1.8 )

can it be, cause the note talk from GPIO16 and GPIO17, ( GPIO PAD PINS ) ,
that we drive the eMbeddedFlash and the external SRAM with the same (slower ) CLK
( btw which pin is used? - there is given SD_CLK from VDD_SDIO domain )
and use we GPIO20 ( was in the VDD_SDIO domain ) then as CS for the external SRAM ?

short:
in which mode we connect which pins to external SRAM on ESP32-D2WD ?

EMAC_CLK_OUT ( GPIO16 ) then is not more existent in ESP32-D2WD, cause is used for the eMbeddedFlash, right?
( is this then on other pin or completly not more possible? )

thank you.

best wishes
rudi

[ESP_Sprite]

Sorry for the short reply, but to be honest we haven't really looked t the D2WD/PSRAM combo that much yet... We will do this in the future, including determining which pins to use.