RMT based NeoPixels (WS2812B) flickers when WiFi is used

[Andreas_Mainz]

Hello,

my experience is following:

1.) level shifter is NOT needed
2.) If i use Esp8266 every thing works fine
3.) If i use Esp32 flickering starts -> Timing issue
4.) It does not depend on Wifi and BT off -> still flickering
5.) Most important ist the strip.show() function, i removed it from the code and moved it in a timer interrupt routine

Code: Select all

  timer = timerBegin(0, 80, true);
  /* Attach onTimer function to our timer */
   timerAttachInterrupt(timer, &ISR_Task_10ms, true);
   timerAlarmWrite(timer, [b]9000[/b], true); // alle 10 ms
   timerAlarmEnable(timer);

and in the timer interrupt:

Code: Select all

void IRAM_ATTR ISR_Task_10ms()
{
  strip.show(); // Initialize all pixels to 'off'
}

So flickering is nearly but not completly disappered. The timerinterval is critical, if it still flickers change "9000" value to different
values. See attached the logic analyser tape.

[doragasu]

I have the same problem. I am driving a 16x16 WS2812 LED matrix using RMT driver, and everything works rock solid when WiFi is disabled. Unfortunately enabling WiFi causes some frames to show lots of glitches. Most of the frames work perfect, but some of them get corrupted (sometimes more than half of the pixel are shown wrong). I suppose this has not been fixed.

[doragasu]

Well, it turns out reading the forum helps

I have changed the initialization to be done from a task pinned to core 1 (that I delete when finished using vTaskDelete(NULL)), and that has completely removed the glitches!

[vegethalia]

Hi, I just registered to thank you for your insights
I was suffering from the same "random flickering problem", and pining the led-drawing task to cpu 1 fixed the issue.

On cpu 0 I have the interrupt used to sample from a microphone and -I guess- the Wifi driver.

Thanks!
Vege.

[bkgoodman]

I don't want to get TOO deep into the answer here (considering this thread is soooo old) - but the answer is that the Neopixel handling is very timing sensitive - particularly when you have enough pixels that the data being transmitted has to span more than a single RMT buffer. This means that if you have Wifi interrupts coming in, they can steal cycles away from the RMT handling.

The best theoretical way to fix this is to prioritize RMT interrupts above those of Wifi and network stack. (I've never quite been able to figure this out) - but what I have done with great success several times is to set the CPU affinity for Wifi, LWIP, and my tasks to be on a DIFFERENT core as those that run RTM and the RTM interrupts.

There are some menuconfig options to do these, and the rest involves creating threads (and making sure interrupts) are fixed to the right cores.

The most obvious way to test this is to send something like a flood ping to your ESP device while it's updating pixels, and see if they freak-out or not. They'll definitiley do so - but you should watch this GREATLY subside (and/or go away) with the fixes I mentioned.