LED indicator flashes LED after init (AEGHB-1156)

[renson-thijs-dhaenens]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Hello,

I’m working on a project that uses an RGB LED, which is controlled via the LED indicator component from esp-iot-solutions.

After creating the LED instance using led_indicator_create(), the LED briefly flashes white before starting the breathing effect. I don’t understand why the LED driver drives the pins high for a short duration—this behavior is not desired, as the LED feedback is critical in our application.

I’ve tried various configuration settings for the LED indicator, but haven’t been able to resolve the issue.

Any help or insights would be greatly appreciated.

Best regards,

#define LED_GPIO_RED 4
#define LED_GPIO_GREEN 5
#define LED_GPIO_BLUE 22

  led_indicator_rgb_config_t rgb_config = {
    .is_active_level_high = false,  // common anode, active low
    .timer_inited = false,
    .timer_num = LEDC_TIMER_0,
    .red_gpio_num = LED_GPIO_RED,
    .green_gpio_num = LED_GPIO_GREEN,
    .blue_gpio_num = LED_GPIO_BLUE,
    .red_channel = LEDC_CHANNEL_0,
    .green_channel = LEDC_CHANNEL_1,
    .blue_channel = LEDC_CHANNEL_2,
  };

  led_indicator_config_t config = {
    .mode = LED_RGB_MODE,
    .led_indicator_rgb_config = &rgb_config,
    .blink_lists = led_mode,
    .blink_list_num = BLINK_MAX,
  };

  led_handle_ = led_indicator_create(&config);

  if (led_handle_ == NULL)
  {
    ESP_LOGE(TAG, "Failed to create LED indicator handle");
  }

    led_indicator_start(led_handle_, STARTUP_BREATHE);

[renson-thijs-dhaenens]

I think I found a solution in the led indicator component.

The flag "invert output" should be set according to the is_active_level_high configuration parameter

led_rgb.c 43-51

ledc_channel_config_t red_ch_cfg = LEDC_CHANNEL_CONFIG(cfg->timer_num, cfg->red_channel, cfg->red_gpio_num);
red_ch_cfg.flags.output_invert = cfg->is_active_level_high ? false : true; // Set output invert for active-low configuration
ret = ledc_channel_config(&red_ch_cfg);
LED_RGB_CHECK(ESP_OK == ret, "red ledc_channel_config fail!", goto EXIT);

ledc_channel_config_t green_ch_cfg = LEDC_CHANNEL_CONFIG(cfg->timer_num, cfg->green_channel, cfg>green_gpio_num);
green_ch_cfg.flags.output_invert = cfg->is_active_level_high ? false : true; // Set output invert for active-low configuration
ret = ledc_channel_config(&green_ch_cfg);
LED_RGB_CHECK(ESP_OK == ret, "green ledc_channel_config fail!", goto EXIT);

ledc_channel_config_t blue_ch_cfg = LEDC_CHANNEL_CONFIG(cfg->timer_num, cfg->blue_channel, cfg->blue_gpio_num);
blue_ch_cfg.flags.output_invert = cfg->is_active_level_high ? false : true; // Set output invert for active-low configuration
ret = ledc_channel_config(&blue_ch_cfg);
LED_RGB_CHECK(ESP_OK == ret, "blue ledc_channel_config fail!", goto EXIT);

Following lines should be removed so no manual adjustment of the duty is made, but managed by ledc:

led_rgb.c 75-79

if (!p_rgb->is_active_level_high) {
    rgb[0] = p_rgb->max_duty - rgb[0];
    rgb[1] = p_rgb->max_duty - rgb[1];
    rgb[2] = p_rgb->max_duty - rgb[2];
}

[YanKE01]

Hi, @renson-thijs-dhaenens . Thank you very much for your feedback. Currently, the ledc part of led_indicator determines whether to invert the duty cycle based on is_active_level_high. In theory, when is_active_level_high is low, manually inverting the duty cycle (without using flags.output_invert = 1) should have the same effect as setting flags.output_invert = 1 in the LEDC driver (removing the manual inversion). Does directly using the output inversion provided by the LEDC driver resolve your issue?

[YanKE01]

I also tried making some modifications based on the existing test_apps to simulate your initialization (I'm using the ESP32-S3-DevKit-C1 board), and found that no waveform was generated during led_indicator_create. There are some methods that may help with debugging — for example, can you test the waveform output of the three GPIOs responsible for LED_RGB on the ESP32 individually? I'm not sure whether there might be interference from the external circuitry.

TEST_CASE("TEST LED RGB", "[LED RGB][RGB]")
{
    led_indicator_rgb_config_t led_grb_cfg = {
        .is_active_level_high = false,
        .timer_inited = false,
        .timer_num = LEDC_TIMER_0,
        .red_gpio_num = LED_RGB_RED_GPIO,
        .green_gpio_num = LED_RGB_GREEN_GPIO,
        .blue_gpio_num = LED_RGB_BLUE_GPIO,
        .red_channel = LEDC_CHANNEL_0,
        .green_channel = LEDC_CHANNEL_1,
        .blue_channel = LEDC_CHANNEL_2,
    };

    led_indicator_config_t config = {
        .mode = LED_RGB_MODE,
        .led_indicator_rgb_config = &led_grb_cfg,
        .blink_lists = led_rgb_blink_lst,
        .blink_list_num = BLINK_RGB_NUM,
    };

    led_handle_0 = led_indicator_create(&config);
    TEST_ASSERT_NOT_NULL(led_handle_0);
    esp_err_t ret = ESP_OK;

    while (1)
    {
        vTaskDelay(1000 / portTICK_PERIOD_MS);
    }

Here's the test menu, pick your combo:
(1)     "blink test all in order" [LED][indicator]
(2)     "blink test with preempt" [LED][indicator]
(3)     "blink three LED" [LED][indicator]
(4)     "User defined blink" [LED][indicator]
(5)     "Preempt blink lists test" [LED][indicator]
(6)     "breathe test" [LED][indicator]
(7)     "custom mode test" [LED][indicator]
(8)     "test gamma table" [LED][indicator]
(9)     "test led preempt func with breath" [LED][preempt][breath]
(10)    "TEST LED RGB" [LED RGB][RGB]
(11)    "TEST LED Strips by RGB" [LED Strips][RGB]
(12)    "TEST LED RGB control Real time " [LED RGB][Real time]

Enter test for running.
10
Running TEST LED RGB...
I (22651) led_indicator: LED Indicator Version: 1.1.1
I (22652) led_indicator: Indicator create successfully. type:LED RGB mode, hardware_data:0x3fce99f4, blink_lists:custom

[renson-thijs-dhaenens]

Hi, @renson-thijs-dhaenens . Thank you very much for your feedback. Currently, the ledc part of led_indicator determines whether to invert the duty cycle based on is_active_level_high. In theory, when is_active_level_high is low, manually inverting the duty cycle (without using flags.output_invert = 1) should have the same effect as setting flags.output_invert = 1 in the LEDC driver (removing the manual inversion). Does directly using the output inversion provided by the LEDC driver resolve your issue?

Hi,

When I use the inversion from the LEDC driver, the issue is resolved. It looks like when the LEDC driver is initialised without inversion, the output is set high.
What is the reason of using a manual invert when it is available in the LEDC driver?

[YanKE01]

Hi, @renson-thijs-dhaenens . Thank you very much for your feedback. Currently, the ledc part of led_indicator determines whether to invert the duty cycle based on is_active_level_high. In theory, when is_active_level_high is low, manually inverting the duty cycle (without using flags.output_invert = 1) should have the same effect as setting flags.output_invert = 1 in the LEDC driver (removing the manual inversion). Does directly using the output inversion provided by the LEDC driver resolve your issue?

Hi,

When I use the inversion from the LEDC driver, the issue is resolved. It looks like when the LEDC driver is initialised without inversion, the output is set high. What is the reason of using a manual invert when it is available in the LEDC driver?

Using the built‑in inversion of the LEDC driver seems like a good suggestion, and we will try it in the next minor release of led_indicator.

[YanKE01]

Hi, @renson-thijs-dhaenens . I did some tests on the LEDC driver. If flags.output_invert is not enabled, the LEDC IO will output a low level by default, which in your case directly lights up the RGB LED — matching the phenomenon you observed. If flags.output_invert is enabled, the LEDC IO will output a high level by default, so configuring LEDC will indeed not cause the RGB LED to light up.

[renson-thijs-dhaenens]

@YanKE01, thanks for testing.
Can you tag me when this has been added to the next release?

[YanKE01]

@YanKE01, thanks for testing. Can you tag me when this has been added to the next release?

Of course.