Page 1 of 1

RMT transaction on led strip corrupted by WiFi interrupts

Posted: Thu Aug 01, 2024 9:56 am
by Pixellord
Greetings,

I am working on a project in which I use RMT of ESP32S3 to transmit data on a LED strip and WiFi for LED configuration. I have observed that some of the LEDs will flicker especially when the number of connected sockets changes in WiFi driver. And the LEDs will be much more stable if WiFi is off.

The LED driver I am using is https://components.espressif.com/compon ... /led_strip (version 2.5.3). So far I have done the following changes and the flickering still exists:
1. DMA is enabled on RMT Tx
2. the freeRToS thread that calls the LED driver (led_strip_new_rmt_device) runs in Core 1.
3. WiFi task is pinned to Core 0 in menuconfig. So do the other application threads in freeRToS.
4. the priority of interrupts in RMT TX is set to level 3. Higher than 3 is not possbile.
5. SPI RAM config: allocate memory of WiFi and LWIP in SPIRAM first. [/list]

I don't understand why the RMT transaction is still corrupted by WiFi driver because the tasks and ISR are supposed to run on different cores. Does anybody have any idea? Thanks!

Re: RMT transaction on led strip corrupted by WiFi interrupts

Posted: Fri Aug 02, 2024 2:41 am
by ESP_Sprite
Can you post your code?

Re: RMT transaction on led strip corrupted by WiFi interrupts

Posted: Fri Aug 02, 2024 7:51 am
by Pixellord
Configuration of the LED driver
  1. esp_err_t ledSetup()
  2. {
  3.    
  4.     led_strip_config_t strip_config = {
  5.         .strip_gpio_num = LED_RMT_TX_GPIO,        
  6.         .max_leds = LED_MAX_LENGTH,              
  7.         .led_pixel_format = LED_PIXEL_FORMAT_GRB,
  8.         .led_model = LED_MODEL_WS2812,            
  9.         .flags.invert_out = false,              
  10.     };
  11.  
  12.     led_strip_rmt_config_t rmt_config = {
  13.         .clk_src = RMT_CLK_SRC_DEFAULT,    
  14.         .resolution_hz = 10 * 1000 * 1000, // 10MHz
  15.         .flags.with_dma = true,            
  16.     };
  17.     ESP_RETURN_ON_ERROR(led_strip_new_rmt_device(&strip_config, &rmt_config, &h_led_strip),
  18.                         TAG, "failed to init RMT device");
  19.  
  20.     return ESP_OK;
  21. }

Thread for LED strip
  1. xTaskCreatePinnedToCore(&mode_init, "mode_thread", 8192, NULL, 24, NULL, 1);
Thread for WiFi. I have mdns also running on core 0.
  1. xTaskCreatePinnedToCore(wifi_app_task, "wifi-app", 8192, NULL, 6, NULL, 0);

Re: RMT transaction on led strip corrupted by WiFi interrupts

Posted: Wed Aug 07, 2024 7:18 am
by Pixellord
ESP_Sprite, do you have any idea?

Re: RMT transaction on led strip corrupted by WiFi interrupts

Posted: Wed Aug 07, 2024 8:59 am
by dmitrij999
Do you need to use multiple RMT channels for different LED strips?
As for me, I worked this around by using SPI

Re: RMT transaction on led strip corrupted by WiFi interrupts

Posted: Wed Aug 07, 2024 12:23 pm
by Pixellord
Hi dmitrij999, thanks for help. I am only using one RMT channel for one strip.
Workaround with SPI would be my last option if i really could not fix it with RMT.

Re: RMT transaction on led strip corrupted by WiFi interrupts

Posted: Wed Aug 07, 2024 1:35 pm
by Bryght-Richard
I saw this once, but it was 2.4GHz radio transmission was sagging power supply slightly, so then RMT bitstream level was not reaching VIH level for LED strip.

Re: RMT transaction on led strip corrupted by WiFi interrupts

Posted: Thu Aug 08, 2024 1:26 am
by ESP_Sprite
That could be it, tbh. If you're using DMA, I'm not sure what else could interrupt the data stream.

Re: RMT transaction on led strip corrupted by WiFi interrupts

Posted: Thu Aug 08, 2024 7:47 am
by Pixellord
Thank you for the help. I think I found the cause of my problem. The DMA buffer size for RMT is by default too small in my case. The data frame has to break into several pieces and then extra delay caused by WiFi is then added in between the fragments. I have increased the mem_block_symbols in led_strip_rmt_config_t and then I don't see any unexpected error on LED strip so far.