V16 won't run on M5STACK AtomS3 Lite (ESP32S3) with M2 screw hole, 8Mb flash and without PSRAM

[403-err]

What happened?

After upgrading the AtomS3 Lite to version 16 the web interface shows the error "Error 8: Effect RAM depleted”.

To Reproduce Bug

Simply install version 15.4 to an Atoms3 Lite and confirm full function, then upgrade to v16. The web interface will show "Error 8: Effect RAM depleted” and the attached Led will not work

Expected Behavior

Since it works fine under 15.4 should it not still function under v16 ?

Install Method

Binary from WLED.me

What version of WLED?

WLED Version 16.0

Which microcontroller/board are you seeing the problem on?

ESP32-S3

Relevant log/trace output

Anything else?

I build a debug version and traced the source of the error to a _pixel buffer allocation in FX_fcn.cpp that uses the flag BFRALLOC_ENFORCE_PSRAM but since the Atoms3 Lite has no PSRAM the allocation fails and thus the error mesage.

I tried a build with following change

diff --git a/wled00/FX_fcn.cpp b/wled00/FX_fcn.cpp
index cbd937fb..0c999ce4 100644
--- a/wled00/FX_fcn.cpp
+++ b/wled00/FX_fcn.cpp
@@ -1274,7 +1274,7 @@ void WS2812FX::finalizeInit() {
   // allocate frame buffer after matrix has been set up (gaps!)
   p_free(_pixels); // using realloc on large buffers can cause additional fragmentation instead of reducing it
   // use PSRAM if available: there is no measurable perfomance impact between PSRAM and DRAM on S2/S3 with QSPI PSRAM for this buffer
-  _pixels = static_cast<uint32_t*>(allocate_buffer(getLengthTotal() * sizeof(uint32_t), BFRALLOC_ENFORCE_PSRAM | BFRALLOC_NOBYTEACCESS | BFRALLOC_CLEAR));
+  _pixels = static_cast<uint32_t*>(allocate_buffer(getLengthTotal() * sizeof(uint32_t), BFRALLOC_PREFER_PSRAM | BFRALLOC_NOBYTEACCESS | BFRALLOC_CLEAR));
   DEBUG_PRINTF_P(PSTR("strip buffer size: %uB\n"), getLengthTotal() * sizeof(uint32_t));
   DEBUG_PRINTF_P(PSTR("Heap after strip init: %uB\n"), getFreeHeapSize());
 }

Is this a valid change? Is there a better fix?

Code of Conduct

• I agree to follow this project's Code of Conduct

[softhack007]

BFRALLOC_ENFORCE_PSRAM but since the Atoms3 Lite has no PSRAM the allocation fails and thus the error mesage.

@DedeHai how would your allocation function react in case a binary is compiled with BOARD_HAS_PSRAM, but no PSRAM access is possible (psramFound() == false) ? Would we automatically fall back to SRAM / IRAM?

I think we already have another report where the wrong PSRAM mode lead to error 8 #5593

[softhack007]

function, then upgrade to v16

@403-err can you explain a bit more how you performed the update? Did you use OTA, upload from VSCode via USB, or another method? Which file did you use for uploading?

[403-err]

Originally I did an OTA update using the v16 version of what it was running (ESP32-S3_4M_qspi) but that resulted in a non functional device.

So I used https://install.wled.me/ to USB flash it but that didn't function either. That image was ESP32-S3_8MB_opi

So at that point I OTA'ed every v16 S3 image but I was not able to get it functioning, so I compiled ESP32-S3_4M_qspi from source to debug and maybe fix the problem.

[DedeHai]

BFRALLOC_ENFORCE_PSRAM but since the Atoms3 Lite has no PSRAM the allocation fails and thus the error mesage.

@DedeHai how would your allocation function react in case a binary is compiled with BOARD_HAS_PSRAM, but no PSRAM access is possible (psramFound() == false) ? Would we automatically fall back to SRAM / IRAM?

no, if BOARD_HAS_PSRAM is defined the assumption is that it does have it. But would be easy to add such a check.

[netmindz]

Yeah I hit this error too on different hardware. The comment and the code are out of sync, it says prefer but actually just fails without, which leaves the device totally unusable with the console just streaming about no pixels in a debug build.

We do need to do something about the web installer, either try the version that Jason thinks is not 100% guaranteed to correctly detect PSRAM or give users of S3 more choice of which image to initial.

Changing the flags as suggested seems like a good suggestion to me though, unless we are going to surface the issue of why everything is broken to the user with explanation as to how they fix

[DedeHai]

it says prefer but actually just fails without

if BOARD_HAS_PSRAM is defined, it uses "enforce PSRAM" for main pixelbuffer. this can changed to "prefer" and it will fall back.

[softhack007]

if BOARD_HAS_PSRAM is defined, it uses "enforce PSRAM" for main pixelbuffer. this can be changed to "prefer" and it will fall back.

@DedeHai yeah, that's better, I think.

People seems to struggle with understanding what PSRAM is, and simply install binaries not matching their boards (... all attempts to educate them have failed in the last 3 years 🤷‍♂️ ).
In best case, WLED will start, but we cannot access any PSRAM despite BOARD_HAS_PSRAM.

[willmmiles]

if BOARD_HAS_PSRAM is defined, it uses "enforce PSRAM" for main pixelbuffer. this can be changed to "prefer" and it will fall back.

@DedeHai yeah, that's better, I think.

People seems to struggle with understanding what PSRAM is, and simply install binaries not matching their boards (... all attempts to educate them have failed in the last 3 years 🤷‍♂️ ). In best case, WLED will start, but we cannot access any PSRAM despite BOARD_HAS_PSRAM.

+1 This is the right way. BOARD_HAS_PSRAM should compile in PSRAM support -- paying the flash size penalty for the extra logic -- but not require PSRAM presence. (We already fixed this for the JSON buffer in c86d09c.) We also already re-enable the PSRAM pins if it's not found. (Really it should be called BOARD_SUPPORTS_PSRAM but we're stuck with the framework name...)

[softhack007]

+1 This is the right way. BOARD_HAS_PSRAM should compile in PSRAM support -- paying the flash size penalty for the extra logic -- but not require PSRAM presence.

@DedeHai @willmmiles I just found (another) subtle difference between the tasmota core and standard (espressif) arduino core:
Tasmota skips the initial "PSRAM health test" at startup, so psramFound() returns true but still PSRAM free = 0.

---

esp32-s3 without PSRAM, tasmota core (full debug)

entry 0x403c98b8
[    44][I][esp32-hal-psram.c:96] psramInit(): PSRAM enabled

---WLED 17.0.0-dev 2605011 INIT---
esp32 4.4.8.240628
arduino-esp32 v2.0.17
CPU:   ESP32-S3 rev.0, 2 core(s), 240 MHz.
FLASH: 8 MB, Mode 0 (QIO), speed 80 MHz.

strip buffer size: 120B
Heap after strip init: 292160B

=== Memory Info ===
DRAM 8-bit:   Free:  214644 bytes | Largest block:  204788 bytes
PSRAM:        Free:       0 bytes | Largest block:      0 bytes  (   <--- psramFound() == TRUE)
RTC RAM:      Free:    7648 bytes | Largest block:    7156 bytes

---

esp32-s3 without PSRAM, espressif core (full debug)

entry 0x403c98d0
E (303) psram: PSRAM ID read error: 0x00ffffff, PSRAM chip not found or not supported, or wrong PSRAM line mode
[   302][W][esp32-hal-psram.c:71] psramInit(): PSRAM init failed!

strip buffer size: 120B
Heap after strip init: 273500B

---WLED 17.0.0-dev 2605011 INIT---
esp32 v4.4.6-dirty
arduino-esp32 v2.0.14
CPU:   ESP32-S3 rev.0, 2 core(s), 240 MHz.
FLASH: 8 MB, Mode 0 (QIO), speed 80 MHz.

=== Memory Info ===
DRAM 8-bit:   Free:  192416 bytes | Largest block:  176116 bytes
PSRAM:        Free:       0 bytes | Largest block:      0 bytes (   <--- psramFound() == FALSE)
RTC RAM:      Free:    7648 bytes | Largest block:    7156 bytes

[DedeHai]

psramFound() returns true but still PSRAM free = 0.

I have seen that in V4 builds a long time ago and my impression was therefore that psramFound() is equal to BOARD_HAS_PSRAM, hence the "bug" that I fixed yesterday - "do not assume PSRAM even if BOARD_HAS_PSRAM"