Needed additional pins for PSRAM

[rudi ;-)]

In D2WD, the flash chip is connected internally to GPIOs 6 (clk), 7(wp), 8(d), 11(hd), 16(cs), 17(q). This is pre-configured using SPICONFIG_ block of fields in the EFUSE.

thanks ivan and thanks for support it now in IDF now i wait for feedback from sales

best wishes
rudi

[ESP_igrr]

q2222ch: this is correct, it is connected via GPIO matrix.

WiFive: it can work at 80MHz, it's just that the GPIO matrix delays signals by extra two cycles (IIRC) at that frequency. Software configures the SPI controller to take this into account.

[q2222ch]

Thank you ESP_igrr for the confirmation. We are waiting for feedback concerning the QFN48 5x5 devices from sales, too.

[rudi ;-)]

Thank you ESP_igrr for the confirmation. We are waiting for feedback concerning the QFN48 5x5 devices from sales, too.

which combine you plan?
ESP32-D0WD with PSRAM
ESP32-D2WD with PSRAM

do you can share your (ESP32-D2WD) - design on your board? -> pm if you not want just in time to public it.


best wishes
rudi

[alangman]

Hi q2222ch,

Are you sharing the SPI channel for the internal FLASH ESP32-D2WD with the ESP-PSRAM?
For connecting an external ESP-PSRAM with ESP32-D2WD using the same SPI channel, are you connecting the PSRAM as follows;

GPIO8(psram_d) ,GPIO17(psram_q), GPIO7(psram_wp), GPIO11(psram_hd) and then use GPIO7(psram_cs) and GPIO8(psram_clk) ?

Best
A

[q2222ch]

Hello alangman,
we have decided to use the ESP32-D0WD instead of the ESP32-D2WD in our project with the PSRAM because we can not make sure that the capacity of the internal SPI flash of the ESP32-D2WD will fulfil all the requirements during the product life cycle. We reduced the needed space for this solution (ESP32-D0WD + PSRAM) by using chips in smaller packages.

[iosixllc]

Does this mean GPIO9 and GPIO10 can be used instead of GPIO16 and GPIO17? Also, are the pins physically wired or can the GPIO matrix be used to switch out the pin functions? Thanks!

[rudi ;-)]

No, sorry. The flash and psram have slightly different timing requirements, and the intrinsics of the cache mechanism makes it impossible to cater to both using one clock line. I was surprised by that myself as well and suggested a few workarounds to the digital team, but seems they already thought of all of them and the only way to make it work is by using a separate clock line.

separate clock line

then sry - this info in the tech referenz manual is then wrong and a bug - please add me to the bug bounty for it

Side 79

0_pSRAM-ESP-tech_ref.jpg (63.07 KiB) Viewed 15068 times

ivan tweets last hours the same and i think then the referenze manual need an update asap and very fast.


now the pSRAM puzzle becomes more face

D0WD:
we need 1.8V, S3:S0 share pins, CLK and CS is difference to the Flash, pSRAM use IO16 for CS and IO17 for CLK

D2WD:
we need 1.8V
In D2WD, the flash chip is connected internally to GPIOs 6 (clk), 7(wp), 8(d), 11(hd), 16(cs), 17(q).
This is pre-configured using SPICONFIG_ block of fields in the EFUSE.

and now we know the CS( IO16) and CLK (IO17) pin in Wrover.
so we can now use and test the wrover we bought from espressif in the past with PSRAM support.

the information is hidden on the street - you just have to find it and put it together.
this info in the technical referenze manual Is very dangerous -
i am glad the routing here in the PCB has not yet finished and charged tasks;
it is the same theme as for SD and SD host. many have wrongly shared the pins - and gived up the next Revision ( olimex REV B comes not out! )

but now we hear from ivan and jeroen the facts. so i will bookmark this for psram here for the future askings and reference and for it.

one new info we get today to:

Okay, can i finally give the reason why we don't burn the efuse for 1.8V in D2WD. The reason is, if the VDD_SDIO is configured by efuse, it takes some time for the hardware to read efuse values at startup. If the strapping pin configures VDD_SDIO to be 3.3V, then during this time, VDD_SDIO will be 3.3V. As soon as efuse read is complete, the regulator will switch to 1.8V.

We never learn everything here - and out.
Every day we learn more

[q2222ch]

Hello I would like to ask a hypothetical question:
If I make the following assumptions:
1.) I use the ESP32-D0WDQ6 or ESP32-D0WD or the ESP32-S0WD chip
2.) I would have a pSRAM chip with a nominal supply voltage of 3.3V at my disposal...
3.) I connect the external SPI flash and the pSRAM chip to the "VDD_SDIO" output pin of the internal LDO of the ESP32 only (with reasonable supply decoupling, VDD_SDIO not connected to VDD3P3_RTC)
4.) I configure the internal LDO that it has the same output voltage as VDD3P3_RTC (as it is mentioned in the data sheet V1.4, page 9).

Would this not be the solution to the pin strapping/ eFuse Deep-Sleep problems?- In the datasheet V1.4, page 9 it is explicitly mentioned that the LDO can be powered off/ the output can be disabled even if the LDO is bypassed/ outputs the same voltage as VDD3P3_RTC:

"The internal LDO can be configured as 1.8V, or the same voltage as VDD3P3_RTC. It can be powered off via software to minimize the current of flash/ SRAM during the Deep-sleep mode."

Is my understanding of the datasheet correct?
If yes: The next question for me is: Why does Espressif not use a "wide VDD" SPI flash in the ESP32-D2WD?- This way round everything could work for the ESP32-D2WD, too (the device could be used with 1.8V or 3.3V VDD_SDIO)?

Thank you for an answer.

[ESP_igrr]

If you use a hypothetical 3.3V pSRAM and a 3.3V flash, both powered from VDD_SDIO, and you configure the internal LDO by means of an Efuse or a strapping pin, then there should be no issues with deep sleep. That being said, i do not understand what kind of problems you mean by "eFuse Deep-Sleep problems".