search

Aircoookie / WLED

Control WS2812B and many more types of digital RGB LEDs with an ESP8266 or ESP32 over WiFi!
https://kno.wled.ge
MIT License
14.6k stars 3.14k forks source link

Random flashing #3592

Open PizzaSauce23 opened 9 months ago

PizzaSauce23 commented 9 months ago

What happened?

Random flashing when running effects. Appears to be software issue. Using esp8266. Voltage and data checked all good.

To Reproduce Bug

Running effects. Bright random flash. No flash if effect is stopped.

Expected Behavior

No flashing

Install Method

Binary from WLED.me

What version of WLED?

14.0 Hoshi

Which microcontroller/board are you seeing the problem on?

ESP8266

Relevant log/trace output

No response

Anything else?

No response

Code of Conduct

declan2511 commented 9 months ago

I am also getting a random flash. I'm running 16500 seed pixels in my xmas display across numerous controllers (esp8266, espcam32 and esp32devkit4). I was running a self compiled version of 14 b3, but I've upgraded to hoshi, which is much better. Still seeing the random flashes, generally on the same channel. Seems worse on Pride, but I have also seen it on a few other sequences.

It does seem to get better the longer the display is running, but very hard to pin down...I've tried everything! For what ever reason, I didn't see it in pre-christmas testing :(

I'm planning some more testing over the weekend. I don't see any similar effects on espixelstick.

On the plus side, l'm loving WLED! Thank you for your great work....lots of happy kids in our Village, really love the Xmas display

pojlFDlxCOvZ4Kg8y1l4 commented 9 months ago

The flashing is something I also have noticed. This has been the case for me since I started using WLED (web installer 0.13 ish up to the current self compiled 0.15 beta) on ESP32s (S2, C3, Pico D4, and normal variants) with DIY 5v hardware. Initially I thought it was due missing level shifters, or "meh" power supplies. Changing power supplies with better or worse did not change the flashing. With better DIY hardware including recommended level shifters the flashing kept being an issue so I bought an Athom WLED ESP32 device. random flashes keep happening.

softhack007 commented 9 months ago

To reduce random flashing on esp32 boards, it might help to set flash memory to the highest possible speed. It will reduce the likelihood that background operations (filesystem, wifi) cause jitter in ongoing LED data transmissions.

Add this to your custom build environment in platformio_override.ini: 

board_build.f_flash = 80000000L ; use full 80MHz speed for flash (default = 40Mhz) 
board_build.flash_mode = dio ; (dio = dual i/o; or qio = quad i/o)

Then hit build & upload in VSCode.

Important: You need to build & upload WLED from the development environment (VSCode+platformIO) for this to work. A different bootloader is needed to change the flash memory speed. Yoa can't achieve it by OTA, and you can't reliably do if with other flash upload tools.

declan2511 commented 9 months ago

thanks softhack007 switching to 80mhz seems to have reduced the flashing, although it's still there. I'll keep experimenting.

blazoncek commented 9 months ago

If you are using MQTT, HomeAssistant, etc. Disable them all.

declan2511 commented 9 months ago

Thanks - I actually think the flash has gone completely - I can't see a flicker on one that has been running for 1 hour (ESP32Devkit, using 10 channels 200 per pixels channel. Christmas is saved:)

blazoncek commented 9 months ago

Be mindful that 80MHz flash may not be reliable on every ESP.

pojlFDlxCOvZ4Kg8y1l4 commented 9 months ago

If you are using MQTT, HomeAssistant, etc. Disable them all. Be mindful that 80MHz flash may not be reliable on every ESP.

I have also experienced this with WLED devices not tied to extra services like HA/MQTT, however, I have not tried the 80MHz flash yet. Could take a few days, I'm sick atm but i'll give feedback if it fixed it or not with the 80MHz flash and without HA/MQTT.

Birkenstab commented 8 months ago

Most ESP32s have 2 Cores. Can Wled use the second core to only do the LED output and use the other core for everything else?

blazoncek commented 8 months ago

WLED uses both cores.

Akaricchi commented 8 months ago

I have a similar issue with two ESP32-S3 boards: YD-ESP32-S3 (DevKitC clone), 16MB flash and 8MB PSRAM (both qio). board_build.f_flash is already set to 80000000L.

I've deduced that most (if not all) flashes happen when there's an incoming HTTP request (e.g. tweaking things in the UI), especially to /presets.json. Requesting that URL reliably corrupts the strip data signal every single time, and messages such as Slow effects and Slow strip appear in the debug log. This is unfortunate, because Home Assistant really likes to query that specific URL periodically. I've disabled the HA integration for now, and the flashes seem mostly gone. But I would really like to control my lights with HA.

Requesting /presets.json seems to read the file from flash every time. Maybe it's worth trying to cache it in PSRAM.

blazoncek commented 8 months ago

It just means CPU can't cope with the load and misses a beat.

Birkenstab commented 8 months ago

Is there a way to fix this? I haven't encountered anything like this with a ESP8266, although it should be quite a bit slower.

Akaricchi commented 8 months ago

I made a quick and dirty patch to serve presets.json from PSRAM instead of reading it off the flash every time. It seems to be working well for me; I've let it run for a few hours yesterday with the HA integration enabled, and I don't think I saw any flashes (except after modifying presets, which invalidates the cache). I realize that some caching is supposed to happen client-side, but in practice it doesn't seem to work reliably.

This patch is a proof of concept and has a few issues, e.g. it assumes the existence of PSRAM and I'm not sure if cache invalidation works properly in every case. Good enough for my personal use, and I can polish it up if there's interest in merging it upstream.

It just means CPU can't cope with the load and misses a beat.

That only seems to happen during flash operations though. Otherwise it handles the effects just fine. I'm running a strip of 273 SK6812 LEDs on one instance, and the remaining 27 on the other. Both exhibit the same behavior.

blazoncek commented 8 months ago

@Akaricchi the patch seems ok to me with a few things you'd need to modify to make it robust.

I should also mention that accessing PSRAM requires some interrupts to be masked (and code running during PSRAM access to reside in IRAM) similar to accessing flash memory (though it is faster) so the resolution may not always work as expected (and may cause crashes if other code is not written correctly).

As for "only happens during flash access": it should be common knowledge that flash memory is way slower than regular RAM when reading it. It should also be common knowledge that writing to flash can be many times slower than reading it. With ESP architecture program code mainly resides in flash memory but ESP uses "smart" caching to cache relevant code in faster cache RAM. Most of the WLED code that is executed millions of times per second has already been put into IRAM and is never fetched from flash for faster execution but many other parts have not as the IRAM is very limited. So flash access will always happen, most of the times unnoticeable, but there may be times when this is more apparent depending on the build options used.

Akaricchi commented 7 months ago

and also add verification if PSRAM exists and is useful (sample elesewhere in WLED code)

I've tried checking psramFound() before doing the allocation, but that had a nasty side effect: it corrupts the result of file.read(). The read seems to be randomly offset in some way, i.e. a part of the actual file is written into the buffer along with some random garbage that happens to be adjacent to it… or that's what it looks like to me. I'm not familiar with the ESP32 architecture at all, so I'm not sure what's going on here.

toha-tiger commented 5 months ago

Hi

I'm also having the same random flashing issue. I'm using ESP WROOM 32 module. Matrix consist of two led strips, 1200 leds in total. 4 external psu 2 per each strip. No level shifters. (same setup previously ran esp8266 with artnet - no flashing issues)

Here are some observations, hope it might help:

(edit) v0.13.0-b5 - also flashes

blazoncek commented 5 months ago

See: https://github.com/Aircoookie/WLED/issues/3837#issuecomment-2017481230

github-actions[bot] commented 1 month ago

Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs. Thank you for using WLED! ✨

swifty99 commented 1 month ago

Hello, same here.

3 strings of 122 SK6812 LEDS on ESP32 flashed moderately at 14.2 for string3 strong flashes at 15.0. b4 at string 1 and string2 -> I can rule out HW issues.

SW driven LED drivers will always suffer. ESP32 has nice HW thogh.