ESP32 and ESP32 S3 PSRAM enabled (IDFGH-10755)

[alberk8]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I have enable the config as show below and when deployed on a non PSRAM hardware the WIFI will not connect. Is there a workaround or additional config that would make this work? The same exact code would work if CONFIG_ESP32_SPIRAM_SUPPORT is set to n

IDF: 4.4.5

for ESP32

CONFIG_ESP32_SPIRAM_SUPPORT=y
CONFIG_SPIRAM_BOOT_INIT=y
CONFIG_SPIRAM_IGNORE_NOTFOUND=y

for ESP32 S3

CONFIG_ESP32S3_SPIRAM_SUPPORT=y
CONFIG_SPIRAM_BOOT_INIT=y
CONFIG_SPIRAM_IGNORE_NOTFOUND=y

Update:
Additional Information. when calling the esp_wifi_init it return out of memory error (257).

[ciniml]

Hi. The same issue has occured on my environment. esp_wifi_init returns 257 after enabling PSRAM.

ESP-IDF: v4.4.4 (e8bdaf9)
Board: ESP32-S3-DevKitC-1-N8R8

The bootloader log says that the PSRAM is initialized correctly.

SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3808,len:0xe3c
load:0x403c9700,len:0xc44
load:0x403cc700,len:0x2e28
entry 0x403c98f0
D (342) flash HPM: HPM with dummy, status is 3
I (342) opi psram: vendor id : 0x0d (AP)
I (343) opi psram: dev id    : 0x02 (generation 3)
I (346) opi psram: density   : 0x03 (64 Mbit)
I (351) opi psram: good-die  : 0x01 (Pass)
I (355) opi psram: Latency   : 0x01 (Fixed)
I (360) opi psram: VCC       : 0x01 (3V)
I (365) opi psram: SRF       : 0x01 (Fast Refresh)
I (370) opi psram: BurstType : 0x01 (Hybrid Wrap)
I (376) opi psram: BurstLen  : 0x01 (32 Byte)
I (381) opi psram: Readlatency  : 0x02 (10 cycles@Fixed)
I (387) opi psram: DriveStrength: 0x00 (1/1)
W (392) PSRAM: DO NOT USE FOR MASS PRODUCTION! Timing parameters will be updated in future IDF version.
D (402) MSPI Timing: tuning success, best point is index 5
I (407) spiram: Found 64MBit SPI RAM device
I (412) spiram: SPI RAM mode: sram 80m
I (417) spiram: PSRAM initialized, cache is in normal (1-core) mode.
I (424) cpu_start: Pro cpu up.
I (427) cpu_start: Starting app cpu, entry point is 0x40375120

After some investigation, esp_wifi_init_internal called from esp_wifi_init returns ESP_ERR_NO_MEM (257).
(by inserting a else clause and put ESP_LOGE to dump result value returned from esp_wifi_init_internal)

esp-idf/components/esp_wifi/src/wifi_init.c

Line 274 in e8bdaf9

}

[jimmo]

We're seeing this in MicroPython too. We build generic firmware images for both S2 and S3, with the following sdkconfig:

CONFIG_SPIRAM=y
CONFIG_SPIRAM_BOOT_INIT=y
CONFIG_SPIRAM_IGNORE_NOTFOUND=y
CONFIG_SPIRAM_USE_MALLOC=y

Our goal is that the generic S2 firmware image will work on any S2 board with or without spiram (and same for the generic S3 firmware). This works on S3, but on S2, we see the error described above when initialising wifi (via esp_wifi_init).

See the MicroPython issue here: micropython/micropython#12750

In some cases we also see

E (666693) esp_netif_lwip: esp_netif_new: Failed to configure netif with config=0x3ffd8a50 (config or if_key is NULL or duplicate key)
E (666693) esp_netif_lwip: esp_netif_new: Failed to configure netif with config=0x3ffd8a50 (config or if_key is NULL or duplicate key)

printed by esp_netif_create_default_wifi_sta before esp_wifi_init_internal returns ESP_ERR_NO_MEM.

Tested on both IDF 5.0.2 and 5.2-dev (commit f8d2c0894c).

[projectgus]

Hi Espressif folks, hope you're all doing well. 👋

We figured this out in the case of MicroPython. By default if CONFIG_SPIRAM is enabled then "Wi-Fi TX Buffers" are enabled and the default config tries to allocate 32 * 1700 = 54,400 bytes of additional memory when esp_wifi_init() is called with WIFI_INIT_CONFIG_DEFAULT.

If PSRAM is not available, this obviously either fails to allocate or limits the free heap at runtime.

We fixed it like this:

wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
#if CONFIG_SPIRAM_IGNORE_NOTFOUND
if (!esp_psram_is_initialized()) {
    cfg.cache_tx_buf_num = 0;
    cfg.feature_caps &= ~CONFIG_FEATURE_CACHE_TX_BUF_BIT;
}
#endif
esp_wifi_init(&cfg);

See micropython/micropython#12968

BTW, it is a bit weird that setting cache_tx_buf_num to zero isn't enough to disable this feature, and double weird that the default value of feature_caps is a global variable in RAM (g_wifi_feature_caps) that otherwise isn't used for anything and could be a macro. 🤷

[jack0c]

@projectgus good to hear from you again. It is related with a feature cache TX buffer, currently it is meaningful and therefore usable if there is a SPIRAM chip which provides large size of external memory. The original design didn't consider the case without SPIRAM but with CONFIG_SPIRAM.

Normally, cfg.feature_caps &= ~CONFIG_FEATURE_CACHE_TX_BUF_BIT; will be the main switch of the feature. If it is disabled, cfg.cache_tx_buf_num = 0; should not affect. We will consider if there are any bugs here.
For the feature_caps here, it is not necessary to be a variable, maybe the original reason is to make the code more simple and readable. Will consider more suitable way.

To support the case without SPIRAM but with CONFIG_SPIRAM, there is one more thing to consider: the recommended Wi-Fi/LWIP buffer configure for the cases with SPIRAM and without SPIRAM are different. Do you think it is acceptable that we set all of buffer number to default number without SPIRAM if detect SPIRAM fail?

[projectgus]

Thanks @jack0c, good to talk to you too!

For the feature_caps here, it is not necessary to be a variable, maybe the original reason is to make the code more simple and readable. Will consider more suitable way.

Thanks for the explanation. Would it be enough for the Wifi library to test cfg.cache_tx_buf_num != 0 for this feature, then?

To support the case without SPIRAM but with CONFIG_SPIRAM, there is one more thing to consider: the recommended Wi-Fi/LWIP buffer configure for the cases with SPIRAM and without SPIRAM are different.

Thanks for the note. I added some more changes in the MicroPython PR:
https://github.com/micropython/micropython/pull/12968/files

On ESP32-S3 the memory usage of Wi-Fi now seems the same as when compiled with !CONFIG_SPIRAM.

Do you think it is acceptable that we set all of buffer number to default number without SPIRAM if detect SPIRAM fail?

Actually I don't think this is an ESP-IDF bug. However, it's important for the user to consider the settings if CONFIG_SPIRAM_IGNORE_NOTFOUND is set. Each application may wish to change or not change some settings, depending on their needs.

Maybe it is enough to add a note in the help for CONFIG_SPIRAM_IGNORE_NOTFOUND, reminding that even if PSRAM doesn't initialize there are other features that may have the SPIRAM default values set?

[jack0c]

@projectgus have confirmed that
CONFIG_FEATURE_CACHE_TX_BUF_BIT enabled but cfg.cache_tx_buf_num == 0 is not supported, but CONFIG_FEATURE_CACHE_TX_BUF_BIT enabled and cfg.cache_tx_buf_num == 1 will work
see 4953f59

Maybe it is enough to add a note in the help for CONFIG_SPIRAM_IGNORE_NOTFOUND, reminding that even if PSRAM doesn't initialize there are other features that may have the SPIRAM default values set?

Yes, it is more flexible if we just added some notes in the help of CONFIG_SPIRAM_IGNORE_NOTFOUND, we can also add some warnings in the places where the features deeply on the SPIRAM.