Cannot set PSRAM for an ESP32S3 board

[martinberlin]

Describe the bug I updated the title since this is solved and I was too lazy to make just another Issue to figure out the PSRAM issue. The fact is, even if I add the attributes for external RAM:

{
  "parts": [
    { "type": "board-esp32-s3-devkitc-1", 
     "id": "esp", "top": -0.18, "left": -5.03, 
    "attrs": { "psramSize": "8", "flashSize": "4" }
}

Hi @urish and @Koepel A demo in the previous link to the project. Checking if PSRAM is recognized with:

  if(psramInit()){
    Serial.println("\nPSRAM is correctly initialized");
    Serial.print("Total PSRAM:");
    Serial.println(ESP.getPsramSize());
    Serial.print("Free PSRAM: ");
    Serial.println(ESP.getFreePsram());
  }else{
    Serial.println("PSRAM not available");
  }

in a physical board using Arduino IDE and setting the Tools-> PSRAM to enabled it works. Doing the JSON setting with Wokwi it does not and that will really not let me simulate the environments and libraries I want, since I use big displays, and many components are highly dependant on external RAM to draw their display framebuffers.

To Reproduce

https://wokwi.com/projects/401153784260252673

Expected behavior

Would like to define a board with external RAM and be able to use it correctly in the program.

[Koepel]

I noticed yesterday that the "psramSize" attribute does not show in the ESP.getPsramSize(). The "flashSize" can be set and shows with ESP.getFlashChipSize().

Here is a cleaner test: https://wokwi.com/projects/401048162688611329 Tested with ESP32, ESP32-S3, ESP32-S2, ESP32-C3. The ESP.getPsramSize() returns zero when the "psramSize" attribute is set to 4.

[urish]

When compiling with Wokwi's compiler, PSRAM is disabled by default.

It can be enabled by compiling the sketch on your own computer, e.g., through the Arduino IDE:

I've just tested the project @Koepel linked by compiling on my own PC, and I can see it correctly detects the PS RAM size:

[martinberlin]

Ah ok thanks will try again with VSCode but I was actually compiling the Firmware with esp-idf where it is for sure PSRAM enabled and I still cannot detect it. I’m trying to build a Wokwi example to test epdiy that is an Espressif based Eink controller and it needs external RAM by default since stores there the whole display frame buffer.

question:

I've just tested the project @Koepel linked by compiling on my own PC

that means we won’t be able to test this in the browser based version of Wokwi?

[urish]

Ah ok thanks will try again with VSCode but I was actually compiling the Firmware with esp-idf where it is for sure PSRAM enabled and I still cannot detect it.

It should work, but I need to see the complete setup to understand why you are not getting the expected result.

that means we won’t be able to test this in the browser based version of Wokwi?

Not necessarily - if there's a board with PSRAM enabled by default (such as the S3 Box), it would still be available.

[Koepel]

So the ESP32-S3-BOX is at the moment the only board that has it enabled by default ? Printing to the Serial Monitor did not work, but the values can be printed to the screen:

  tft.setTextSize(2);
  tft.setCursor(36, 106);
  tft.println(ESP.getPsramSize());
  tft.setCursor(36, 136);
  tft.println(ESP.getFreePsram());

[urish]

So the ESP32-S3-BOX is at the moment the only board that has it enabled by default ?

I believe so. Yeah, Serial monitor goes to the USB Serial+JTag port, which is not (yet) exposed by Wokwi, it's in the works.

[martinberlin]

Printing to the Serial Monitor did not work, but the values can be printed to the screen:

This one I really don't understand. Why it does not also print it to serial but it works when printing it on the display?

About what I'm trying to do: https://github.com/vroland/epdiy/issues/325 I'm a collaborator in epdiy that is a Espressif raw Eink controller (Parallel like the ereader displays, not SPI like the supermarket prices) and what we would like to do as an initial step, is to initialize the board and see how the parallel and sync signals come out of the controller.# For that what I would like to do initially is just to build one of the examples that draws a Dragon in the display: https://github.com/vroland/epdiy/compare/main...325/wokwi-testing build it in the command line using idf.py build And then reference the Firmware in the wokwi.toml file and try to open it in the VSCODE.

At the moment I have configured the ESP-IDF to use Octal PSRAM and this is what I get when I initialize Wokwi in VSCODE: _octalpsram: PSRAM ID read error: 0x00000000, PSRAM chip not found or not supported, or wrong PSRAM line mode

So it seems that even if it's built ready to detect PSRAM, that it does correctly flashing this to an epdiy v7 board, then it would not work in Wokwi. There is any way to tell wokwi that I'm using this kind of RAM?

By the way if any of you, or both of you would like to try epdiy to understand better how it works, I have boards ready to send you free of charge since I take care of the fabrication of PCBs to sell in Tindie. And I always reserve some for developers and collaborators of the project. And wokwi is definivaly the next step in our CI chain.

[urish]

This one I really don't understand. Why it does not also print it to serial but it works when printing it on the display?

There are at least three types of serial interface on ESP32 chips, and the ESP32-S3 has all of them:

• Hardware UART
• UART over USB (full blown USB peripheral)
• UART over USB (minimal hardware USB with Serial port + JTAG)

Wokwi supports the first two, the third one is still WiP. The the S3-Box uses the third one :)

At the moment I have configured the ESP-IDF to use Octal PSRAM and this is what I get when I initialize Wokwi in VSCODE: octal_psram: PSRAM ID read error: 0x00000000, PSRAM chip not found or not supported, or wrong PSRAM line mode

I think if you configure it to use a 16-mbyte PSRAM it'll default to an octal PSRAM. Not sure though - I think we only tested octal psram simulation ESP32-P4 so far.

[martinberlin]

I think if you configure it to use a 16-mbyte PSRAM it'll default to an octal PSRAM.

Thanks confirming that this idea worked out perfectly:

I (5527) heap_init: At 3FC95DB8 len 00053958 (334 KiB): DRAM I (5533) heap_init: At 3FCE9710 len 00005724 (21 KiB): STACK/DRAM I (5540) heap_init: At 3FCF0000 len 00008000 (32 KiB): DRAM I (5546) heap_init: At 600FE010 len 00001FD8 (7 KiB): RTCRAM I (5553) esp_psram: Adding pool of 16384K of PSRAM memory to heap allocator

This can be closed now. Anyways in my opinion this external RAM part should be documented a bit more since is hard to figure out how to make it work. The PSRAM is detected with the setup I mentioned previously (Firmware built and menuconfig in IDF using Octal PSRAM) but it does not work in the web simulator And that I think is like @urish mentioned because in the Web interface you lack the Arduino IDE setting to use PSRAM, hence compiling it just with the parameter in diagram.json won't enable it by default. But is still not clear for me why it does it for S3-box and not for other boards. It would be cool to have a way to enable it for any board that has the psram setting active. And is nice to be able to do it "per will" since enabling PSRAM always add some milliseconds more to the boot process and for this reason is not good to do it in all scenarios unless you really need to use it.

[urish]

I (5553) esp_psram: Adding pool of 16384K of PSRAM memory to heap allocator

🥳 Thanks for letting us know!

But is still not clear for me why it does it for S3-box and not for other boards.

The S3-box product has PSRAM on board, so the board definition includes PSRAM by default. The other boards do not, so the default is to have PSRAM off. This comes from the board definition file in the esp32 arduino core: https://github.com/espressif/arduino-esp32/blob/master/boards.txt

It would be cool to have a way to enable it for any board that has the psram setting active. And is nice to be able to do it "per will" since enabling PSRAM always add some milliseconds more to the boot process and for this reason is not good to do it in all scenarios unless you really need to use it.

Agreed, but that would require changing the compilation server to support changing the psram setting, which unfortunately involves a non-trivial amount of work.

[martinberlin]

Agreed, but that would require changing the compilation server to support changing the psram setting, which unfortunately involves a non-trivial amount of work.

Thanks I understand better how it works now. I think is fine like it is and for more complicated scenarios then the VSCode version can cover it. You have more possibilities when you build the firmware yourself using your toolchain of choice!