PSRAM init fault when PSRAM does not exist and ignore not-found is set (IDFGH-4204) #6063
Comments
github-actions
bot
changed the title
|
Fix is incoming, thanks for reporting. For now: I think you should be able to work around this indeed by disabling SPIRAM_BOOT_INIT, then calling esp_spiram_init() and if that succeeds, calling |
|
Thanks for the response! I tried this but it appears that whenever I enable I haven't extracted it from our application code but I believe this failure should be reproduced by enabling bluetooth support in menuconfig then instead of configuring it calling |
|
Strange, I'll see if I can look into this. The fix for the original issue, by the way, is an one-liner. In |
|
thanks for all the quick responses! we're currently running against a patched-to-heck version of the dockerhub applying the suggested patch to The v4.2 patch: diff --git a/components/esp32/cpu_start.c b/components/esp32/cpu_start.c
index 791a3b0c4..f9cb6563c 100644
--- a/components/esp32/cpu_start.c
+++ b/components/esp32/cpu_start.c
@@ -186,7 +186,10 @@ void IRAM_ATTR call_start_cpu0(void)
abort();
#endif
}
- esp_spiram_init_cache();
+
+ if (s_spiram_okay) {
+ esp_spiram_init_cache();
+ }
#endif
ESP_EARLY_LOGI(TAG, "Pro cpu up.");The v4.3 version (in case it's useful to anyone else): diff --git a/components/esp_system/port/cpu_start.c b/components/esp_system/port/cpu_start.c
index 92080e000..289411f1d 100644
--- a/components/esp_system/port/cpu_start.c
+++ b/components/esp_system/port/cpu_start.c
@@ -276,7 +276,10 @@ void IRAM_ATTR call_start_cpu0(void)
abort();
#endif
}
- esp_spiram_init_cache();
+
+ if (g_spiram_ok) {
+ esp_spiram_init_cache();
+ }
#endif
#if !CONFIG_ESP_SYSTEM_SINGLE_CORE_MODE
`` |
|
Okay so enabling the PSRAM on a board that has it also appears to cause failures in |
|
right so the culprit is also |
|
Same for esp-idf 3.3.5 Seems to be introduced by See also |
When
CONFIG_SPIRAM_IGNORE_NOTFOUND=yis set initialising a device with SPIRAM enabled causes a fault (rather than continuing to boot without enabling the additional PSRAM)Environment
git describe --tagsto find it): v4.2-dev-2182-gdddcc2edextensa-esp32-elf-gcc --versionto find it): xtensa-esp32-elf-gcc (crosstool-NG esp-2020r2) 8.2.0Problem Description
Configuring SPIRAM with auto-detect and ignore-notfound should (i believe) attempt to check the PSRAM exists and continue booting if not, instead this panics at
esp_spiram_get_chip_size.SPIRAM KConfig fields:
Expected Behavior
The device starts, attempts to detect SPIRAM and fails, then continues booting with available onboard memory.
Actual Behavior
The device detects RAM was not available, continues, and appears to fault while trying to fetch the SPIRAM size. See the logs below.
Steps to reproduce
Debug Logs
Notes
The text was updated successfully, but these errors were encountered: