ESP32 ULP example does not WAKE the SoC when it is not in deep sleep (IDFGH-6712)

[sgalabov]

Problem Description

• The example suggests that READ_RTC_FIELD(RTC_CNTL_LOW_POWER_ST_REG, RTC_CNTL_RDY_FOR_WAKEUP) should be used to check that RTC_CNTL_RDY_FOR_WAKEUP is set before attempting to WAKE the chip.
• The documentation for the WAKE instruction says the following:

Note that before using WAKE instruction, ULP program may needs to wait until RTC controller is ready to wake up the main CPU. This is indicated using RTC_CNTL_RDY_FOR_WAKEUP bit of RTC_CNTL_LOW_POWER_ST_REG register. If WAKE instruction is executed while RTC_CNTL_RDY_FOR_WAKEUP is zero, it has no effect (wake up does not occur).

However, when the SoC is not in deep sleep mode it appears that the RTC_CNTL_RDY_FOR_WAKEUP bit of RTC_CNTL_LOW_POWER_ST_REG is actually never set, so if an ULP program relies on it to signal the SoC to wake up it will never be able to.

Clearer guidelines are needed in the documentation at least on how to achieve reliable WAKE functions both when the SoC is in deep sleep and when it is not.

Using the WAKE instruction without checking for the RTC_CNTL_RDY_FOR_WAKEUP bit of RTC_CNTL_LOW_POWER_ST_REG seems to work fine most of the time, but the documentation and example suggest that this may not be reliable and we may fail to wake the SoC up by just calling WAKE when the SoC is in deep sleep and RTC_CNTL_RDY_FOR_WAKEUP is not set.

Expected Behavior

To be able to have the ULP signal the SoC reliably both when the SoC is in deep sleep and when it is not.

Actual Behavior

If we follow the example wake up works when the SoC is in deep sleep, but does not work otherwise.

How to Reproduce

I use this simple gist in place of ulp_example_main.c from the example to confirm the failure to signal the SoC from the ULP when waiting for the RTC_CNTL_RDY_FOR_WAKEUP to be set while the SoC is not in deep sleep. Then, if I just call WAKE without waiting for RTC_CNTL_RDY_FOR_WAKEUP to be set everything seems to work as expected.

[sgalabov]

Having continued to look for the answer I found #5254, which, if valid, would answer my question too.
It would be nice to get it properly documented for posterity... :-)
If someone can confirm that the solution suggested in #5254 is valid I am ok with closing this issue, of course.