Strange flickering colours on ESP32 using FastLED

[Borgling]

Describe the bug Strange flickering colours behaviour with esp32 and FastLED library

To Reproduce

#define LED_PIN    26
#define LED_TYPE    WS2812B
#define COLOR_ORDER GRB
#define NUM_LEDS    256

CRGB leds[NUM_LEDS];

void setup() 
{
  FastLED.addLeds<WS2812B,LED_PIN,GRB>(leds, NUM_LEDS);
}
void loop() 
{
  for(int i = 0; i<NUM_LEDS;i++)
  {
    leds[i] = CRGB::SkyBlue;
  }
    FastLED.show();
}

https://wokwi.com/projects/396609731378879489

Expected behavior Solid sky blue with no change

Environment (please complete the following information):

• OS: Windows
• Browser Chrome
• Version 124.0.6367.61

Additional context Seems to work fine with Arduino (nano tested)

[urish]

Thanks for reporting!

This happens due to some of the optimizations we're doing with ESP32. They work well in (almost) every scenario - FastLED is the exception. A workaround would be to disable the optimizations, by changing line 6 in diagram.json to read:

    { "type": "wokwi-esp32-devkit-v1", "id": "esp", "top": 80, "left": 20, "attrs": { "__timingOptimizations": "disable" } },

This will make the simulation somewhat slower, but the weird artifacts should go away.

Can you please test this work around and report back?

[Borgling]

Using "__timingOptimizations": "disable" , makes things works as expected. Thank you!

Btw is the esp32 emulator/simulator open source? I was going to take a look at debugging it myself, but couldn't seem to find the source. Now I'm just curious to take a look under the hood :)

[urish]

Excellent!

The ESP32 emulator is not open source at the moment. But if you are curious, it's very similar in nature to the RP2040 simulator at https://github.com/wokwi/rp2040js.

I also presented a few bits on my 2021 Remoticon Talk: Reverse Engineering the ESP32 WiFi.

From my experience, this kind of issues are the most difficult to debug - you have to debug both the program running in the simulation, and the simulator, and understand which of the assumptions the program is making does not hold true in the simulation. And given the complexity of the ESP32 (dual core, RTOS, etc.), finding timing issues is pretty tricky. In this case, IIRC, the FastLED expects to execute a certain amount of code between the interrupts from the RMT peripherals (where it requests the next chunk of data), and with the timing optimizations are enabled, this expectation does not hold true anymore. Therefore, it sometimes misses the deadline, RMT reads old data, and then you get artifacts.

[tschundler]

Should this really be closed, or by default disable __timingOptimizations?

I've been working on esp_hal rust RMT changes and ran into this same problem. The suggested flag fixes it. I was thinking the bug was on my end until I tried with real hardware.

There RMT leave enough time for 1000s of instructions (>28us) before depleting half of the ring buffer. But half in the emulator, it seems to loop through the ring buffer in the time of only a few hundred instructions.

[urish]

Should this really be closed, or by default disable __timingOptimizations?

Unfortunately, just disabling timing optimizations (which has now been replaced by cpuFrequency means that the simulation will run much slower for everyone. In most cases, capping the CPU frequency results in much faster simulation speed, which still providing good value for the users.

RMT is one of the few cases where this might break. One way we are mitigating it is by going up for the max frequency during interrupt handlers - at least some of the implementation I've seen refill the buffer within the interrupt handler. In theory, we could have some kind of heuristic that will go up for the max frequency for a certain number of instructions after each RMT write.

Are you experiencing this across all ESP32 family chips? or just in specific chips?

[tschundler]

I was just testing was original ESP32, I hadn't thought to try others in simulation. I was figuring for testing hardware before release, I'd try the ESP32S3 + C3 I have handy. Maybe I'll try them in Wokwi too.

A configurable number is a good option - playing with values, I can see that my code works at 40MHz simulated, which reaches ~80% of realtime when running. Which a lot faster than setting the speed to 240.

SGTM to keep this closed. Maybe the real feature request then is discoverability of the options for components.