led_strip corrupts the signal when used inside a task (IEC-271)

[michaesc]

Answers checklist.

• I have read the component documentation ESP-IDF Components and the issue is not addressed there.
• I am using target and esp-idf version as defined in component's idf_component.yml
• I have searched the issue tracker for a similar issue and not found any related issue.

Which component are you using? If you choose Other, provide details in More Information.

led_strip

ESP-IDF version.

v5.4

Development Kit.

Custom board

Used Component version.

2.4.1 and 3.0.0

More Information.

Using led_strip to drive a WS2812B works correctly as shown, even when the led_strip based driver is placed inside a FreeRTOS task started by xTaskCreate().

But when a second FreeRTOS task (with gpio_reset_pin(), gpio_set_direction(), and gpio_set_level() functions to cycle a standard LED connected to a GPIO) is started, the led_strip generated signal is corrupted. Instead of a periodic blinking white light, the WS2812B either stays dark or is constantly bright green.

#include "esp_log.h"
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "taskstrip.h"
#include "taskgpio.h"

// Implementation of a silly do nothing task
void vTaskNone(void *pvParams)
{
    while(1) {
        ESP_LOGI("Nonetask", "Not doing anything!\n");
        vTaskDelay(1000 / portTICK_PERIOD_MS);
    }
}

void app_main(void)
{
    // Declare handles for the different tasks to run
    TaskHandle_t xHandleStrip = NULL, xHandleGpio = NULL, xHandleNone = NULL;

    // Create tasks to run concurrently
    // The vTaskStrip is in another source file, similar to get-started/blink
    xTaskCreate(vTaskStrip, "RGBStrip", 2048, NULL, 8, &xHandleStrip);
    configASSERT(xHandleStrip);
    xTaskCreate(vTaskGpio, "GPIOFlip", 2048, NULL, 8, &xHandleGpio);
    configASSERT(xHandleGpio);

    //if (xHandle != NULL) {
    //    vTaskDelete(xHandle);
    //}
}

We are trying to blink two LEDs using two FreeRTOS tasks. The first LED is a WS2812B driven by led_strip and the second LED is a standard LED connected to a GPIO of the ESP-32C3 MCU. It should be easy to blink two LEDs in this way, by starting each of the drivers in a FreeRTOS task and watching the blinking done concurrently.

RMT and SPI

It doesn't matter whether the led_strip RMT or SPI driver is used. The successful (no second task) control flow works with either RMT or SPI. The flawed (including a second task) control flow fails on either RMT or SPI.

Question

Why is the WS2812B blink logic failing when a second task starts?

Suspicion

Can it be, that the FreeRTOS scheduler is preempting the led_strip driving logic and corrupting the signal when control is switched to other tasks?

[michaesc]

The answer to my question is that using the GPIO 12 on a ESP32-C3 part with embedded flash is unsupported and the MCU behaviour becomes undefined. When I change from GPIO 12 to GPIO 13 for the discrete LED output, then the logic works correctly.