I have tested this with three ESP32’s with WLED 0.14.0-b1 and I am experiencing a randomly-timed controller lockup that requires a power cycle for the controller to become responsive again. I first experienced this issue while connected to a 504-pixel string of WS2815’s. In further testing, this occurs even without being connected to a string. It also occurs with multiple separate 5v poser supplies, all of which are 5A+ and test fine for ripples, noise, as well as voltage sag.
ESP32-ETH01 - My first time I experienced this phenomena. I flashed this using the Chrome browser flash utility. Everything boots ok and effects are visible in Peek for about 10-15 seconds, then lockup occurs, requiring a power cycle before I can ping the module or access the web interface. For a few days it would run for hours before locking up. Now it’s locked up within seconds of turning the lights on.
ESP32-WROOM32U with External Antenna - This board was flashed with the 0.14.0-b1 binary using the esptool.py via the command line and instructions on the Install WLED Binary page. Everything boots ok and effects are visible in Peek for about 10-15 seconds, then lockup occurs, requiring a power cycle before I can ping the module to access the web interface. Totally different power supply and no strings are connected to the board. Peek is used to show the effect running, then locking up, as well as the error on the web interface that the connection was lost. After a power cycle I can ping and access the webui once more.
ESP32-WROOM32U Onboard Antenna - Flashed with the ESPhome-flasher tool using a newly-downloaded copy of the 0.14 firmware binary. Exact same issue as the other two boards on a totally different power supply with no LED’s connected to the board. Peek is used to time the malfunction timing, as well as the error on the web interface that the connection was lost. After a power cycle I can ping and access the webui once more.
What am I missing here? I have tried three different install methods, two seperate downloads of the 0.14.0-b1 firmware, three different power supplies, nothing is connected to the boards but power and GND for testing purposes. I find it hard to believe that I have three bad ESP32’s when my WEMOS D1 Minis run for months without a burp.
Any thoughts before I tear the rest of my hair out?
Use a debug build and monitor serial output. If no LEDs are required to reproduce the outcome, then it should be fairly simple to dump the crash/lockup.
I hate to ask, but I am needing some help getting a debug build working.
When building from the 0.14.0 source in PlatformIO, I added #define WLED_DEBUG to wled.cpp and the terminal is throwing the following complaints during the build:
wled00/wled.cpp: In member function 'void WLED::loop()':
Retrieved `.pio\build\esp32_eth\liba99\WiFi\ETH.cpp.o' from cache
wled00/wled.cpp:187:18: error: 'debugTime' was not declared in this scope
if (millis() - debugTime > 29999) {
^
wled00/wled.cpp:201:26: error: 'lastWifiState' was not declared in this scope
if (WiFi.status() != lastWifiState) {
^
wled00/wled.cpp:202:7: error: 'wifiStateChangedTime' was not declared in this scope
wifiStateChangedTime = millis();
^
wled00/wled.cpp:204:5: error: 'lastWifiState' was not declared in this scope
lastWifiState = WiFi.status();
Retrieved `.pio\build\esp32_eth\liba99\WiFi\WiFi.cpp.o' from cache
^
wled00/wled.cpp:208:9: error: 'loops' was not declared in this scope
if (loops > 0) { // avoid division by zero
^
wled00/wled.cpp:213:11: error: 'class WS2812FX' has no member named 'printSize'
strip.printSize();
^
wled00/wled.cpp:214:5: error: 'loops' was not declared in this scope
loops = 0;
^
wled00/wled.cpp:221:3: error: 'loops' was not declared in this scope
loops++;
^
If I leave the WLED_DEBUG out of the definitions it compiles just fine. Thoughts?
You don’t do that.
You should use PIO build environment and add -D WLED_DEBUG to build_flags. Or, if you must change source files add #define to wled.h.
You can also use a bin from @srg74 repository as instructed by @tonyno .
Thank you all or the help. I was finally able to get home and work on this.
I was able to build 0.14.0-b1 in PIO with the -D WLED_DEBUG flag and uploaded to the board. I ran three tests with lockups occurring each time. Three logs were captured which can be found here:
https://drive.google.com/drive/folders/1o6rwzOYsgHvkcLOOyISEjNn-S56nyG0G?usp=sharing
The common theme I see is that this is serial output immediately before the module becomes unresponsive:
URI: /presets.json
FileRead: /presets.json
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
Not-Found HTTP call:
URI: /presets.json
FileRead: /presets.json
When doing a bit of digging, it appears that someone else had this issue with 0.13.0 and the issue was closed when 0.13.1 was released. @blazoncek, it looks like this one has come around again.
https://github.com/Aircoookie/WLED/issues/2551
To be thorough, I wiped the flash and re-uploaded the 0.14.0-b1 debug build, reconfigured the LED strip settings, created couple new presets using the WebUI and added them to a playlist, then hit play. After a couple minutes the same behavior of becoming unresponsive occurred, which was preceded by the same “FileRead: /presets.json” error.
Thoughts?
That did it!
Can you shed some light on what was happening? I have a bunch of WLED devices all over the house with Home Assistant controlling them, however this is the first time I have seen this issue.
HA polls too often, causing resource depletion on ESP.
Use ESP32 if you need HA integration and have low memory condition on ESP.
Gotcha. Interesting thing is that my Wemos D1 Mini’s with ESP8266’s work fine, but the ESP32 that I recently started using is the one that is having issues.
Odd. That should not happen.