ledcFade can lead to dead-lock on ESP32-classic

[TD-er]

Board

ESP32 (classic)

Device Description

ESP32-classic

Hardware Configuration

Nothing attached to the board

Version

latest master (checkout manually)

IDE Name

PlatformIO

Operating System

Windows 11

Flash frequency

40MHz

PSRAM enabled

yes

Upload speed

115200

Description

Several calls to ledcAttach followed by ledcFade on the same pin without calling ledcDetach for that pin will lead to a completely frozen system on ESP32.

N.B. the same code on ESP32-C2 does not show this behavior. Not tested on other ESP32-variants.

Since there doesn't seem to be a simple check to see if a pin is already attached, I added a simple ledcWrite check first to set the start duty cycle for the upcoming fade.
If this returns false, I run ledcAttach on that pin.

So either of these 2 variants do work:

    if (!ledcWrite(gpio, start_duty)) {
      // Pin not yet attached
      if (!ledcAttach(gpio, frequency, resolution)) {
        return false;
      }
    }

    if (!ledcFade(gpio, start_duty, target_duty, fadeDuration_ms)) {
      return false;
    }

    ledcDetach(gpio);
    if (!ledcAttach(gpio, frequency, resolution)) {
      return false;
    }

    if (!ledcFade(gpio, start_duty, target_duty, fadeDuration_ms)) {
      return false;
    }

Sketch

// Not working code
while (true) {
    if (ledcAttach(gpio, frequency, resolution)) {
      ledcFade(gpio, start_duty, target_duty, fadeDuration_ms);
    }
    delay(2*fadeDuration_ms);
}

Debug Message

Node just freezes after a few calls
Probably due to the semaphore code in ledcFadeConfig

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[SuGlider]

@TD-er - based on the fact that you are using the C2 to test it, I guess that this is about Arduino Core 3.0.0-Alpha2.
Is it correct?

@P-R-O-C-H-Y - Please take a look. It may be related to this change: https://github.com/espressif/arduino-esp32/pull/9031/files

[TD-er]

Yep, the latest code from Arduino and ESP-IDF.
So it might be that this is even a soon-to-be-bug in Arduino if it doesn't fail yet on your tests :)

[P-R-O-C-H-Y]

Hi @TD-er, I am now taking a look at this. Just quick question, why would you call every time the ledcAttach(), is that because of the pin is using for other purposes also?

[P-R-O-C-H-Y]

I have used you non-working code in testing sketch, but no issues on my side.

// use 12 bit precission for LEDC timer
#define LEDC_TIMER_12_BIT  12

// use 5000 Hz as a LEDC base frequency
#define LEDC_BASE_FREQ     5000

// fade LED PIN (replace with LED_BUILTIN constant for built-in LED)
#define LED_PIN            4

// define starting duty, target duty and maximum fade time
#define LEDC_START_DUTY   (0)
#define LEDC_TARGET_DUTY  (4095)
#define LEDC_FADE_TIME    (3000)

void setup() {
}

void loop() {
    if (ledcAttach(LED_PIN, LEDC_BASE_FREQ, LEDC_TIMER_12_BIT)) {
      ledcFade(LED_PIN, LEDC_START_DUTY, LEDC_TARGET_DUTY, LEDC_FADE_TIME);
    }
    delay(2*LEDC_FADE_TIME);
}

Serial output:

[139902][V][esp32-hal-periman.c:229] perimanSetBusDeinit(): Deinit function for type LEDC (12) successfully set to 0x400d15ec
[139913][V][esp32-hal-periman.c:154] perimanSetPinBus(): Pin 4 successfully set to type INIT (0) with bus 0x0
[139925][V][esp32-hal-periman.c:154] perimanSetPinBus(): Pin 4 successfully set to type LEDC (12) with bus 0x3ffb8464
[139938][I][esp32-hal-ledc.c:116] ledcAttachChannel(): LEDC attached to pin 4 (channel 1, resolution 12)
[145949][V][esp32-hal-periman.c:229] perimanSetBusDeinit(): Deinit function for type LEDC (12) successfully set to 0x400d15ec
[145960][V][esp32-hal-periman.c:154] perimanSetPinBus(): Pin 4 successfully set to type INIT (0) with bus 0x0
[145972][V][esp32-hal-periman.c:154] perimanSetPinBus(): Pin 4 successfully set to type LEDC (12) with bus 0x3ffb8464
[145985][I][esp32-hal-ledc.c:116] ledcAttachChannel(): LEDC attached to pin 4 (channel 0, resolution 12)

Edit: as the pin is not used for anything else, the ledcAttach() should actually fail, as the pin is already attached to LEDC.
This unintended behaviour appears with latest LEDC manual channel selection feature. You can see in output that, the LEDC channel was switching from 0 to 1 and back.

[TD-er]

Hi @TD-er, I am now taking a look at this. Just quick question, why would you call every time the ledcAttach(), is that because of the pin is using for other purposes also?

The actual use case is about letting a LED fade from one state to another state and then back again.
And since it is done via commands from rules in my application, the command just doesn't make any assumptions of the pin state and starts the fade process. (not sure if that's the best approach, but that was how it was done)