Flickering on ESP8266 3.1.2 and 3.1.1

[Souravgoswami]

I'm currently working with this repository:

https://github.com/Souravgoswami/Arduino-FastLED-Cool-Effects

You can find the ino file at this location:

https://github.com/Souravgoswami/Arduino-FastLED-Cool-Effects/blob/master/Arduino-FastLED-Cool-Effects.ino

I acknowledge that the code might not be the most readable, but the main issue I'm facing is random flickering on the WS2811 chains when used with a D1 mini. I've tried different D1 minis and WS2811 chains, but the problem persists, leading me to suspect the low 3.3 logic level, which previously worked without any issues.

To address this, I used the TXS0108E IC to shift the signal level and observed that it performed well when viewed on a scope:

But the same the flickering issue remained unresolved, even with a relatively short signal wire.

Currently, I'm using the HEF4050BP, which does distort the signal slightly, but I don't believe this to be a significant problem:

Here's an image with a single sweep:

Then I did something stupid, I added a Serial.begin(115200) to the setup() function (without any print statements), now the flickering disappeared!

I then removed the Serial.begin and added a counter to my code to increment the design by 1, which also worked perfectly. This leads me to suspect an issue with the compiler.

By default, I compile with the Os optimization level. However, when I tried O2, the flickering intensified.

The flickering disappears with O1, O3, and Ofast levels, suggesting a potential software issue.

Here's the flickering with Os using ESP8266's 3.1.2:

flickering-Os.mp4

And here's the flickering with O2 using the same ESP8266's 3.1.2:

flickering-O2.mp4

The flickering issue persists regardless of the colour of the light. At the Os optimization level, the flickering is greenish hue, and at the O2 level, it appears bluish. Consequently, when I illuminate any colour other than green at the Os level, the flickering becomes noticeable. The same is true at the O2 level when I illuminate any colour other than blue, the flickering becomes visible.

Upon inspecting my software, I didn't find anything particularly suspicious.

I then downgraded to ESP8266's 3.1.0 version from 3.1.2 and found that the flickering disappeared even at Os or O2 levels.

After installing the 3.1.1 library, the flickering returned.

I'm using Archlinux's avr-gcc 13.2.0-2, avr-binutils 2.41-1, avr-libc 2.1.0-3, avrdude 1:7.3-1.

Does anyone have any insights into what might be happening?

I'm unsure whether to report this bug here or to the ESP8266 team, but I'm assuming it's a FastLED bug that doesn't work reliably with 3.1.1+ versions of ESP8266?

At the moment, I believe that deciphering such extensive assembly could be quite challenging for me.

[Souravgoswami]

Ah, this glitch is because of:

#ifdef BOARD_ESP8266
  #define FASTLED_ALL_PINS_HARDWARE_SPI
#endif

Removing that fixed it! This directive instructs the FastLED library to use hardware SPI for LED communication. But WS2811 LEDs require precise timing control that doesn't probably align with standard SPI communication.

By removing this, we revert to software bit-banging, which accurately generates the necessary timing for WS2811 LEDs, eliminating the flickering issue.

---

The compiler message:

157 | # pragma message "No hardware SPI pins defined. All SPI access will default to bitbanged output"

can be confusing, as noted in the discussion here: #1169 (comment)

For LED strips like the WS2811, which rely on precise timing rather than standard SPI protocols, this warning might be misleading. Eliminating or making this message friendlier when using WS2811 chains can prevent the confusion, as these strips are designed for bit-banged output rather than hardware SPI.

[Souravgoswami]

Using two ISR in my code reintroduced the flickering issue, even without defining SPI. I came across the WLED website that provided some guidance:

"All pins can be changed in the Hardware section of LED settings. Please note that these are GPIO numbers, please consult a pinout for your board to find the labeled pin (e.g D4 = GPIO2 on most ESP8266 boards). When using an ESP8266 board, it's recommended to use pins GPIO1, GPIO2, or GPIO3 for LED Data; using other pins will require bit-banging and may cause slow performance and/or issues elsewhere (such as with IR decoding)."

Source: https://kno.wled.ge/basics/getting-started/

Utilizing GPIO 2 eliminated the flickering, but when dimming the LEDs, severe flickering occurs. Additionally, this pin is linked to the ESP8266's onboard LED, which now remains constantly on.

Switching to GPIO 1 also fixed the initial flickering problem but resulted in similar dimming issues. Moreover, GPIO 1 outputs boot debug information, which I personally do not need but others might.

This situation has left me confused about the underlying cause of these issues.

EDIT:
I've notced that when my setup has an array of 10 to 50 CRGB LEDs, everything works smoothly, even with 50 LEDs connected. However, as the number of LEDs increases to 100, a noticeable flickering begins, even though 50 LEDs are connected. This flickering becomes more noticeable with 200 LEDs and significantly worsens with a setup of 300 LEDs.

[Souravgoswami]

I continue to encounter the same problem and have simplified my code to isolate the issue:

#pragma GCC optimize("Os")

#include <Arduino.h>
#include <FastLED.h>

#define NUM_LEDS 70
#define DATA_PIN 2
#define BRIGHTNESS 100

CRGB leds[NUM_LEDS];

void setup() {
  delay(1000);
  FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
  FastLED.setBrightness(BRIGHTNESS);
  FastLED.clear();
}

void loop() {
  leds[0] = CRGB::Red;
  FastLED.show();
  FastLED.delay(1000);

  uint16_t flashDuration = random8(10, 25);
  for (uint16_t i = 0; i < flashDuration; ++i) {
    leds[0] = (random8(10) >= 5) ? CRGB::White : CRGB::Blue;
    FastLED.show();
    FastLED.delay(50);
  }

  uint8_t rapidFlashDuration = random8(10, 20);
  for (uint8_t i = 0; i < rapidFlashDuration; ++i) {
    leds[0] = (i % 2 == 0) ? CRGB::White : CRGB::Red;
    FastLED.show();
    FastLED.delay(50);
  }

  leds[0] = CRGB::Yellow;
  FastLED.show();
  FastLED.delay(1000);
}

With this setup, instead of illuminating only the first LED, it incorrectly lights up 3 - 4 LEDs in sequence with red, blue, yellow, and white colours. Upon connecting a different WS2811 LED chain, the issue disappeared, leaving me suspecting the original chain might be faulty. But when I tested the so-called faulty chain with an Arduino using the same code, no issues were noticed.

Considering a potential signal level mismatch, I used the TXS0108E level shifter to adjust the 3.3V signal from the ESP8266 to 5V, suitable for WS2811. The problem still persisted.

I speculated the issue might stem from signal reflection due to unterminated lines, especially since my setup involves configuring 70 LEDs while only having a 50 LED chain connected. Extending the chain with another WS2811 did not resolve the issue. Curiously, adjusting the NUM_LEDS to 69 in the code eliminates the problem, but reintroducing 70 LEDs brings the issue back, confirming it's not related to the power supply and such.

This anomaly suggests a deeper issue potentially related to how the FastLED library interfaces with the ESP8266, signal integrity, or specific characteristics of the WS2811 LED chain that are exacerbated under certain configurations.

EDIT:
With the exact same code, and even NUM_LEDS = 500 I faced no issues on Arduino nano - the issue is only present on ESP8266.

[Souravgoswami]

Note that #define FASTLED_ALLOW_INTERRUPTS 0 doesn't solve the issue for me:

#pragma GCC optimize("Os")

#define FASTLED_ALLOW_INTERRUPTS 0
#include <Arduino.h>
#include <FastLED.h>

#define NUM_LEDS 100
#define DATA_PIN 14
#define BRIGHTNESS 100

CRGB leds[NUM_LEDS];

void buttonPushEvent();

void setup() {
  delay(1000);
  FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
  FastLED.setBrightness(BRIGHTNESS);
  FastLED.clear();
}

void loop() {
  leds[0] = CRGB::Red;
  FastLED.show();
  FastLED.delay(1000);

  uint16_t flashDuration = random8(10, 25);
  for (uint16_t i = 0; i < flashDuration; ++i) {
    leds[0] = (random8(10) >= 5) ? CRGB::White : CRGB::Blue;
    FastLED.show();
    FastLED.delay(50);
  }

  uint8_t rapidFlashDuration = random8(10, 20);
  for (uint8_t i = 0; i < rapidFlashDuration; ++i) {
    leds[0] = (i % 2 == 0) ? CRGB::White : CRGB::Red;
    FastLED.show();
    FastLED.delay(50);
  }

  leds[0] = CRGB::Yellow;
  FastLED.show();
  FastLED.delay(1000);
}

[robertlipe]

You have some harsh ringing on those rise times.. if you're getting a reflection in the cable, the symptoms can math. Toss a 110 or 220 ohm resistor after the shifter and before the strip. See if that fulls your over and undershoots and leaves you with less crazy rf-like behavior on that bus.

Technically, it'll lower your voltage slightly but more importantly, it'll get rid of the additive over and undershoots that can cause signal misreads. Optimizer setting, color patterns, pixel count, the number of cold drinks in the fridge, the added capacitance of your scope or a finger on the wire, and other crazy things can all move one bit which is enough to make these strands spaz.