I'm not sure if misunderstand the technical reference manual or if my code is incomplete. The manual says ...
"Users can use the hold function for the pads to retain the pad state through a core reset and system reset triggered by watchdog time-out or Deep-sleep events."
... and I would expect that the state of a GPIO pin, set and put on hold by an ULP program, does not change when the ULP program wakes up the chip.
Here's the code fragment I'm using in the ULP program to set and hold GPIO4 (D4).
Code: Select all
WRITE_RTC_REG(RTC_GPIO_OUT_REG, (14 + 10), 1, 1) WRITE_RTC_REG(RTC_CNTL_HOLD_FORCE_REG, 8, 1, 0) WRITE_RTC_REG(RTC_CNTL_HOLD_FORCE_REG, 8, 1, 1)
When the ULP program calls the "wake" command, then the GPIO state gets changed For the counter chip it would be good if the GPIO state does not get changed by the starting ESP32.
Why do I need that?
To reduce the energy consumption I'm using a 8bit-counter chip (74HC590) to count pulses while the ESP32 is in deep sleep. The ULP code gets executed every second to read the counter value, store it, reset the counter and go to sleep again by calling the "halt" command. For debugging the ULP code writes debugging informations to a global field and wakes up the chip (the ULP timer does not get stopped). The main program of the chip prints the debugging data and goes to deep sleep.
Is it possible to retain the GPIO state when the system wakes up and if yes, how?