Hmm, probably more RMT troubles. I'll check it out.

Hi folks, here's a video of the issue in action. Thanks!

I can reproduce a problem by running this in the REPL on a Kaluga:

>>> b = b'\1\1\1\0\0\0' * 240
>>> d = digitalio.DigitalInOut(board.IO18)
>>> while True: neopixel_write.neopixel_write(d, b)
... 

AND continuously writing to the CIRCUITPY drive from Linux:

pi@raspberrypi:~/media/CIRCUITPY $ while sync; do touch boot_out.txt ; done

Here's a "good" neopixel trace from saleae:

good trace, zoomed out:

Here's a "bad" trace, which looks just like the good one to me:

but what is obviously wrong is that in the "zoomed out" view, it takes MUUUUCH longer:

Here's how the strip looked with a glitch: (data comes IN from the RIGHT and shifts to the LEFT):

I investigated the filesystem access "angle" because I believe I see similar disruptions to the neopixel during UF2 bootloading -- the LEDs are mostly blinking yellow/orange, but occasionally a flicker of another color can be seen. This potentially points at a problem outside of CircuitPython, or in implementation code that is shared between CP and the UF2 bootloader. However, Kattni and N+P's scenarios don't seem to involve filesystem/flash access.

Hey folks, I just came across this issue while researching an issue I'm experiencing and it sounds exactly like Kattni described above. I'm using the Tiny S2 from Unexpected maker with a 60 neopixel ring. The animation works just fine apart from random flashes of other colours. It occurs even under the most basic of code conditions. Please let me know if there is anything I can do to help debug.

If it helps, I caught a video of the glitch... it appears towards the end of the video https://www.youtube.com/watch?v=WQKzEdR0QGc

Hi, i have the same issue with a raspberry pico, i use comet animation suddenly some leds show a random color.
I'm using the pl9823 version of neopixels. Any ideas?

@juandoplt you might want to make a new issue, if you're experiencing problems with the RP2040. Since the underlying hardware is totally different, it's very unlikely to be the same issue across both vendors.

One thing to try would be putting the neopixel code in RAM so that its running doesn't have to contend with flash accesses.

An interesting data point which may (or may not) be of use.

I have a Lolin S2-mini (ESP32-S2) running CircuitPython 7.2.3. The device is driving 240 WS2812C-2020 "neopixels".

It's been glitching just as described above.

On the rare occasion where I plug it into my computer (Windows 10), I might get the "Unrecognized USB device" error. In these cases, the device still receive power but does not have any communications. What is relevant here is that it does not glitch in this situation.

So I've been having what might be this problem, on a qt-py-esp32-s2, with 120 neopixels (5x24 circles). Is there a way to tell whether the above RMT driver patch in the micropython code base has made it's way into a circuitpython release?

Also, as yet another data point, the glitch i see matches the other descriptions here (and the video above), however, it only happens when my code does initialize the wifi radio. Specifically, if I execute this line:
wifi.radio.connect(secrets["ssid"], secrets["password"])
the neopixel string flickers. If i comment it out, the flickering ceases. This is the case regardless of whether the qtpy is connected as a USB disk/serial device or just powered on. Circuit python 7.2.5

using:
Adafruit CircuitPython 7.3.0 on 2022-05-23; S2Mini with ESP32S2-S2FN4R2
Board ID:lolin_s2_mini

I can also confirm this bug and the workaround of @jdimpson .

my project use the neopixel a lot but only rarely get info from the web. In the end, I completely shut down the wifi (wifi.enabled=False) between uses to get the flickering stop. This is still not an ideal solution as the whole reconnect, takes some time that is noticeable.

I just saw adafruit is about to offer a NeoPixel BFF for the qt-py form factor. I'm hopeful that as a result, this problem will get more attention. I look forward to synchronizing NeoPixels over wifi!

might be worth checking if this is any different after the idf upgrade.

@jepler I just updated my board and put an equivalent code (refreshing a lot the pixels while staying connected to the wifi). The issue is still here.
From memory the glitch is not exactly the same, so I guess the interrupt occurring during the px.show() might have a different timing...

tested on a lolin s2 board, with 8.2.7

tested on a lolin s2 board, with 8.2.7

The IDF rebase landed as part of the the 9.x release so it won't be in 8.2.7

I finally retested it with 9.0.0-alpha.6, same board: still got the glitches. (I have not proper metric but it feel like there is less of them...)

I notice that we could use the flag ESP_INTR_FLAG_IRAM to allocate the bounce buffer of the RMT peripheral in internal RAM rather than PSRAM. (the IRQ handler is already in IRAM)

I just finally found the time to test again with the latest build available on the s3 (adafruit-circuitpython-lolin_s2_mini-en_US-20240306-main-PR9008-e64082d.bin) and can confirm (if that was needed?) that it works great with my setup that was triggering the issue.

Thanks a lot !!