Re: Another ULP timer question
Posted: Tue Oct 01, 2019 6:12 am
My experiments show that there is an initial sleep on starting the ULP based on the the value put in SENS_ULP_CP_SLEEP_CYC0_REG by calling ulp_set_wakeup_period(), but that's the only delay available from any of these registers in deep sleep mode. I can use that. I haven't done the experiments in light sleep mode. That may work, but light sleep is not what I need.
I tried the experiment you suggested in my own test bed program, that of setting up a loop such that halt was called once to try to set up a sleep, and then bypassing the halt the next time through and returning to the C code. However, the ULP never returned indicating that the ULP never work up on expiry of the sleep period. I don't even know if the sleep period count was actually started. I just know that she never returned. While I could easily be wrong, not knowing the ESP32 all that well yet, this feels like a hardware bug. Do you have any insight?
Another way to test this would be to set up a blinky in the ULP, and then set up, say, a 5 second delay in SENS_ULP_CP_SLEEP_CYC0_REG and then call halt right after returning the C code without ever explicitly starting the ULP again. The blinky will stop when the ULP hits that halt instruction. If "ULP wake after halt-sleep" works, the LED will start blinking again after the halt-sleep expires as long as the ULP jumps around the halt instruction forever. If the LED state remains constant beyond the halt-sleep timeout, wake after halt-sleep doesn't work.
I tried the experiment you suggested in my own test bed program, that of setting up a loop such that halt was called once to try to set up a sleep, and then bypassing the halt the next time through and returning to the C code. However, the ULP never returned indicating that the ULP never work up on expiry of the sleep period. I don't even know if the sleep period count was actually started. I just know that she never returned. While I could easily be wrong, not knowing the ESP32 all that well yet, this feels like a hardware bug. Do you have any insight?
Another way to test this would be to set up a blinky in the ULP, and then set up, say, a 5 second delay in SENS_ULP_CP_SLEEP_CYC0_REG and then call halt right after returning the C code without ever explicitly starting the ULP again. The blinky will stop when the ULP hits that halt instruction. If "ULP wake after halt-sleep" works, the LED will start blinking again after the halt-sleep expires as long as the ULP jumps around the halt instruction forever. If the LED state remains constant beyond the halt-sleep timeout, wake after halt-sleep doesn't work.