Wake up from deep sleep issue after software reset

[ncat_esp32]

I'm experiencing an issue where my ESP32-S3 fails to wake up from deep sleep under specific conditions.

After initial power-up, the ESP32 successfully enters and exits deep sleep via interrupt on an EXT1 pin or by the wakeup timer.
However, if I trigger a deep sleep cycle after previously performing a software reset, the device becomes unresponsive to both EXT1 wake up and timer-based wake-up.
The key difference in this failing scenario is the software reset performed before entering deep sleep.

After investigating this issue further, I discovered that it only occurs when the RTC clock source is configured to Internal 17.5MHz oscillator, divided by 256. When I changed the clock source to Internal 136kHz oscillator, the issue went away.
However, I would prefer to be able to use the Internal 17.5MHz oscillator, divided by 256 as the RTC clock source because of its higher timekeeping accuracy while in deep sleep mode.

Is this the expected behaviour or should I be able to wake from deep sleep after a software reset when using the Internal 17.5MHz oscillator, divided by 256 as the RTC clock source?

[Aria James]

This may be an issue with how the RTC wake-up functionality interacts with the 17.5MHz oscillator. You should be able to wake up after a software reset with that clock, but it's possible there's a bug or conflict in how the RTC is configured.

[embeddedmoose]

I seem to have ran into the same issue, and was pleased to stumble upon this suggestion of looking at the 17.5MHz clock.

I made the change from internal RC to the fast clock as RTC source because it made startup*** time of BLE/Modem during automatic light sleep much longer than it needed to be. With the RC oscillator, BLE would wake for ~100ms before an advertising event. Without it, would only preempt the advertising TX by 7-8ms.

This definitely seems to be in the realm of a silicon or driver issue. Have not found any workaround yet to preserve use of the 17.5MHz clock.

[tpbedford]

This is a known issue in ESP-IDF introduced around 5.4, I think? see:

https://github.com/espressif/esp-idf/issues/16243

It's now been patched, so either apply the patch(es) in the above issue, or get the latest ESP-IDF and check the behaviour again - if it's still present, the patch might not yet be in the release that you're using.