FastLED: ESP32 corrupted data within rmt device
Hi i have a problem with my ESP32 controlled WS2812 LEDS. As long as I do not use Bluetooth or WiFi everything is fine. But after enabling Bluetooth or connecting WiFi to an existing network (AP seems to work fine) Strange things begin to happen in the RMT subsystem.
The problem is a color flickering starting from one (random) LED in the stripe and affecting all following ones appearing about once or twice a second.
First I thought that the problem is due to interruptions by the WiFi or Bluetooth communication but nothing so I tried the following:
- Disable Interrupts: FASTLED_ALLOW_INTERRUPTS 0
- Only using one RMT channel: FASTLED_RMT_MAX_CHANNELS 1
- Remove every other thread from Core 1 (by modifying freeRTOS) xTaskCreatePinnedToCore and xTaskCreate
Nothing helped. So I tried to diagnose the problem by only sending static data to the LEDS and connecting an Oscilloscope to the data channel so every frame should look the same: The first result was that the “bad” frames are a little bit longer than expected. and the content was different too. So it is no issue of the LEDs itself. I expected to see the frame tear appart at some point because of an interrupt disturbing the software during RMT buffer fillup but that was not the case. In fact the data itself seems to be corrupted. I achieved to get an image of a frame that was damaged it the very beginning so it was easy to compare it to a valid frame and found out that after byte 8 things start to get strange. The expected datastream whoul be repeatingly: 00000101 00001100 00000000
Index: 6 7 8 9 10 11 12
Target: 00000101 00001100 00000000 00000101 00001100 00000000 00000101
Actual: 00000101 00001100 00000101 00001100 00000000 00000101 00001100
Index: OK OK NOK NOK 8 9 10
So somehow there get 16 byte inserted into the bitstream after byte index 7 this not only destroys the one pixel but shifts the whole stream and creates wrong colors.
You can find the Image and csv data from the oscilloscope here:
I also tried to replace the rmt code of esp by a very simplified code which causes the same issues.
int cur = 0;
while (pixels.has(1)) {
uint8_t byte = 0x04;
//uint8_t byte = pixels.loadAndScale0();
led_data[cur++] = byte & 0x80 ? mOne : mZero;
led_data[cur++] = byte & 0x40 ? mOne : mZero;
led_data[cur++] = byte & 0x20 ? mOne : mZero;
led_data[cur++] = byte & 0x10 ? mOne : mZero;
led_data[cur++] = byte & 0x08 ? mOne : mZero;
led_data[cur++] = byte & 0x04 ? mOne : mZero;
led_data[cur++] = byte & 0x02 ? mOne : mZero;
led_data[cur++] = byte & 0x01 ? mOne : mZero;
//byte = pixels.loadAndScale1();
led_data[cur++] = byte & 0x80 ? mOne : mZero;
led_data[cur++] = byte & 0x40 ? mOne : mZero;
led_data[cur++] = byte & 0x20 ? mOne : mZero;
led_data[cur++] = byte & 0x10 ? mOne : mZero;
led_data[cur++] = byte & 0x08 ? mOne : mZero;
led_data[cur++] = byte & 0x04 ? mOne : mZero;
led_data[cur++] = byte & 0x02 ? mOne : mZero;
led_data[cur++] = byte & 0x01 ? mOne : mZero;
//byte = pixels.loadAndScale2();
led_data[cur++] = byte & 0x80 ? mOne : mZero;
led_data[cur++] = byte & 0x40 ? mOne : mZero;
led_data[cur++] = byte & 0x20 ? mOne : mZero;
led_data[cur++] = byte & 0x10 ? mOne : mZero;
led_data[cur++] = byte & 0x08 ? mOne : mZero;
led_data[cur++] = byte & 0x04 ? mOne : mZero;
led_data[cur++] = byte & 0x02 ? mOne : mZero;
led_data[cur++] = byte & 0x01 ? mOne : mZero;
pixels.advanceData();
pixels.stepDithering();
}
led_data[cur++] = mReset;
rmtWrite(rmt_send, led_data, cur);
I am out of ideas how to solve this.I hope anyone here can help me?
Best regards Jan
About this issue
- Original URL
- State: open
- Created 5 years ago
- Comments: 26 (11 by maintainers)
Wait, you’re not going to give me your network ID and password?!?!? 😉 OK, I will check this out this evening or tomorrow.