Thanks for reporting/solving this. Espressif guys are making our life difficult recently. They are introducing braking changes to their low level api very often, almost every few months.

Which version of the arduino-esp32 package are you using?

@uLipe do you maybe have some thoughts on this?

We've had a couple of these changes recently that are braking our compilation.
It seems like in the last versions of IDF there are a couple of new attributes added to the ledc and/or mcpwm drivers.
Do you have some insight if there is a way to be a bit more future proof, so that we don't have to release a new version of the library on each arduino-esp32 package release :D

Hello @askuric @bisak , I agree with the solution proposed, it is the best way for fixing it.

Why this causes an error:

• The IDF has a very complex low power framework that is system wide.
• But this framework is aware that some peripherals may need to be enabled even in battery saving scenarios.
• The solution is to use a giant lock called PM_LOCKS which are spread over the drivers, if the driver instance takes it, it cannot be put in sleep mode by the IDF system component.

So telling this driver will be ALIVE during its initialization flow will resulting on taking this driver PM_LOCK and never releasing it which signals the IDF system telling: don't put this peripheral in sleep mode, so this solution is perfect to avoid bad-operation of the LEDC in runtime.

BTW C3 is far more aggressive on its low power framework, that is probably behind the error happens right after you initialize it.

Regarding the future proof, this started to become a concern on the latest versions of IDF 5, but before that, the rule of thumb is, if a particular component is developed under the same major number of IDF it should not break, but when it targets a new IDF (from 4 to 5) it will break.

For the next releases the IDF is being more smooth between these versions, by making an API deprecated before removing it.

What I suggest is still the ugly solution, read the IDF version of the particular arduino core, and add remove code based on it,

cc: @askuric

In that case I will merge it, so that we have the fix in the next release.

Thank you @bisak for this PR, and thank you @uLipe for your insights on it!

Huge thank you for merging this!
Just for the record I was using master of pioarduino, so esp-idf 5.5.1 at present.