ESP32-S3-FN8 SPIRAM errors on boot.

[kdschlosser]

Port, board and/or hardware

esp32 port

MicroPython version

1.23.0

Reproduction

Compile for the ESP32-S3 without a board variant. flash to the ESP32-S3-FN8 series MCU (no PSRAM) and you will get SPIRAM errors when it boots.

Expected behaviour

For MicroPython to start up without logging errors to the console.

Observed behaviour

E (422) quad_psram: PSRAM ID read error: 0x00ffffff, PSRAESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0x15 (USB_UART_CHIP_RESET),boot:0x8 (SPI_FAST_FLASH_BOOT) Saved PC:0x40382ba2 SPIWP:0xee mode:DIO, clock div:1 load:0x3fce3820,len:0x105c load:0x403c9700,len:0x4 load:0x403c9704,len:0xbd8 load:0x403cc700,len:0x2e30 entry 0x403c989c 

E (422) quad_psram: PSRAM ID read error: 0x00ffffff, PSRAM chip not found or not supported, or wrong PSRAM line mode
E (423) esp_psram: PSRAM enabled but initialization failed. Bailing out.

(Then MicroPython continues starting up as normal.)

Additional Information

When I look at the board cmake file I can see it is loading this for the sdkconfig

set(SDKCONFIG_DEFAULTS
    boards/sdkconfig.base
    ${SDKCONFIG_IDF_VERSION_SPECIFIC}
    boards/sdkconfig.usb
    boards/sdkconfig.ble
    boards/sdkconfig.spiram_sx
    boards/ESP32_GENERIC_S3/sdkconfig.board
)

the boards/sdkconfig.spiram_sx is being loaded which contains

# MicroPython on ESP32-S2 and ESP32-PAD1_subscript_3, ESP IDF configuration with SPIRAM support
CONFIG_SPIRAM_MODE_QUAD=y
CONFIG_SPIRAM_TYPE_AUTO=y
CONFIG_SPIRAM_CLK_IO=30
CONFIG_SPIRAM_CS_IO=26
CONFIG_SPIRAM_SPEED_80M=y
CONFIG_SPIRAM=y
CONFIG_SPIRAM_BOOT_INIT=y
CONFIG_SPIRAM_IGNORE_NOTFOUND=y
CONFIG_SPIRAM_USE_MALLOC=y

# This is the threshold for preferring small allocations from internal memory
# first, before failing over to PSRAM.
CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL=8192

This is being done even tho the SPIRAM board variant has not been used.

Code of Conduct

Yes, I agree

[projectgus]

This is being done even tho the SPIRAM board variant has not been used.

For ESP32-S3 MicroPython doesn't use a separate SPIRAM board variant, instead we rely on the CONFIG_SPIRAM_IGNORE_NOTFOUND=y ESP-IDF config option. ESP-IDF should ignore missing PSRAM and keep booting.

In this case it seems like ESP-IDF is reading an unexpected invalid PSRAM ID on boot and treating it as an error.

[projectgus]

Oh,right. The "PSRAM enabled but initialization failed. Bailing out." line is actually the indication that booting will continue.

When you say that you expect it to "run properly", can you please be more specific?

Is the problem that it logs these lines, and then MicroPython starts? Or is the problem that it fails to start at all after printing that output?

[kdschlosser]

It was booting, I just couldn't see it because of how MicroPython is set up and always assigns 2 pins on the S3 for usb otg even if it's not being used for that. This stops being able to use the pins for other things. I disabled the usb otg and as it turns out this specific board I am using uses the usb otg for the repl output. I had simply forgotten to turn it back on.

That is neither here nor there and the error for the SPIRAM should not happen if I did not supply SPIRAM for the board variant. Leaving the board variant unset means there is no SPIRAM and as such it should not be initialized even if it only spits out an error and will continue running. The error shouldn't be there...

[kdschlosser]

1.23.0 does have SPIRAM_OCT as a board variant and it should have a board variant of SPIRAM because not all esp32-s3's have SPIRAM, it is an optional thing. Having an error spit out saying "initialization failed. bailing out" is not really the right thing to do. The config options should be set properly so that error is not produced. All of the pieces are already in place to do this and why it is not being done that way I am not sure. If I don't supply SPIRAM as a board variant when compiling for an ESP32 does the same error occur? No it doesn't and that's because the config options are set properly for that MCU.

[dpgeorge]

All of the pieces are already in place to do this and why it is not being done that way I am not sure. If I don't supply SPIRAM as a board variant when compiling for an ESP32 does the same error occur?

To reduce the number of variants (make it simpler for users, faster build times, less storage taken by all the variants) we have tried to make a "one size fits all" firmware where possible. And that means not having a separate variant for SPIRAM for C3, S2, S3.

instead we rely on the CONFIG_SPIRAM_IGNORE_NOTFOUND=y ESP-IDF config option. ESP-IDF should ignore missing PSRAM and keep booting.

@projectgus do you consider it a bug in the IDF that it's still printing out an error message when SPIRAM is not found, even with this IGNORE_NOTFOUND option enabled?

[projectgus]

I've made some edits to the original issue report to clarify that the problem is the log lines, not any other failure.

1.23.0 does have SPIRAM_OCT as a board variant

This is because it's not possible to have a single binary that supports both octal and quad SPIRAM. Similarly, the original ESP32 (pre-V3) has to compile the entire source with different compiler flags when SPIRAM is enabled which is why it has two variants.

do you consider it a bug in the IDF that it's still printing out an error message when SPIRAM is not found, even with this IGNORE_NOTFOUND option enabled?

We could ask the IDF team about this and if these logs could be lowered to a different log level based on that config setting, or even submit a PR to do this. I don't know what they'll think about it. I don't have a suitable ESP32-S3 without SPIRAM at hand to test on, but I just ordered a few new boards which includes a suitable one.

We could also probably do some hacky link-time patch in MicroPython to swallow those log lines specifically, I guess.

[kdschlosser]

It can be a bit misleading. It should say No PSRAM present. Definitely not the error it is spitting out that's for sure.

What would be great is if the ability to pass any of the ESP32 config settings when make is called and the cmake script would take those extra arguments and pass them to the idf somehow. Or at least provide an argument that could be passed which would be the path to a user supplied sdkconfig file that would get added to the end of the list. This way it would get processed last so if something needed to be overridden it can be done. A fantastic example is adding the additional config settings that are needed to get the 32mb flash version to work properly. The user is also able to tweak things without having to edit any of the micropython files if they so choose to. Having that ability also means the user would be able to supply their own partition file without having to change any of the micropython source. If that ability existed this issues would actually be a non issue because the ability to override the SPIARM setup could be easily done.

[vshymanskyy]

@kdschlosser , this has nothing to do with MicroPython. Please file a ticket for ESP-IDF/bootloader.

The easy way to get rid of these messages would be to disable the bootloader prints altogether:

CONFIG_LOG_BOOTLOADER_LEVEL_NONE=y

[jonnor]

This appears to be outside of MicroPython, but instead in esp-idf.