In ESPCLOCK3, the following reset circuitry was used:
In the ESPCLOCK4, I wanted to try a software-only approach with the ULP. The main idea is the ULP will check the switch (with a little software debounce processing). If it finds the switch depressed, it will wake the main processor, which will then perform a software reset.
This means we will only need a single pushbutton, with one end connected to an input pin (pulled up), and the other end connected to GND. No need for additional resistors/capacitors.
I connect the reset button to GPIO4/GND, and add the following definitions:
The following code is added to init_gpio() to configure the pin as pulled-up input:
Another RTC_SLOW_MEM variable is added to store the wake up reason, which the ULP will use to indicate to the main CPU why it has been woken up.
Also add a macro to read the state of a given GPIO pin:
Now in the ULP, add the following code:
What the code basically does is to read GPIO4. If it is low, it will wait for a debouncing period of 1ms and read the pin again. If it it still low, it writes WAKE_RESET_BUTTON (1) as the reason code to WAKE_REASON. Then it waits for the RTC_CNTL_RDY_FOR_WAKEUP bit to become 1, which indicates that the main CPU is ready for wake up. At this point, we issue:
- I_WAKE() to wake the main CPU
- I_END() to stop the RTC timer, because we don't want to ULP code to be run again
- I_HALT() to stop the ULP code
In the setup() code, an additional line is added to allow the ULP code to wake the main CPU:
The code to handle the wakeup reason is this:
The cause value will tell us whether the main CPU is just starting up, or it is being woken up by the ULP. If it is starting up, it checks GPIO4 to see if the button is still being held down. If so, it can initiate the factory reset logic.
If it is woken up by the ULP, it checks the wake reason to determine the action to take. So if the wake reason is WAKE_RESET_BUTTON, we call esp_restart() to reset the ESP32.
Issue with esp_restart()
After playing around with the code above, it was found that esp_restart() does not always perform a full reset of the ESP32. This resulted in the ULP code not running, or running once and stopping, in a unpredictable manner. This behaviour can be observed every 2 or 3 resets using esp_restart().
I googled around, and this post seems to fit the bill. It also appears esp_restart() has a long history of problems: example, example, example, example. This is because esp_restart() performs a software reset of the unit, which is different from pulling the EN pin low, and sometimes it misses certain things.
After much digging around and hair pulling, I finally found a reliable way to perform a hardware reset of the MCU:
The above code sets the stage 0 timeout for the RTC WDT to 500ms. If the WDT is not "fed" or disabled by the code within that time, a hardware reset signal is initiated. You can see that a hardware reset is performed by connecting the ESP32 to a serial monitor. The same status messages as powering on the ESP32 are displayed when the reset occurs.
When this solution is adopted, everything works as expected. The ULP code runs without a hitch after each reset.