Replies: 4 comments 2 replies
-
machine.reset() is more close to hardware reset than CTRL-d. CTRL-d resets the MicroPython VM, while calling machine.reset() is executing all software from the point after it started after the hardware EN switch. Still, some hardware may not be reset to the power-on state. |
Beta Was this translation helpful? Give feedback.
-
I guess there are good reasons for machine.reset() to not actually reset all the hardware. I recall comments to the effect calling machine.reset() to sort out things like the WiFi losing it's way was not a good solution. In most of my programs I go through setting up WiFi first and then init the hardware. So, if the hardware starts-off in an unwanted state then bad things could happen until you get to the hardware init stage. I am going to shift to doing hw_init as early as possible. As far as my POWERON_RESET hack is concerned it seems to be a better approach when a software watchdog terminates then doing a machine.reset() Does machine.reset() maintain all GPIO state? Maybe, that could be a benefit. |
Beta Was this translation helpful? Give feedback.
-
Update ... the proposed circuit may not be reliable. Possibly a one-shot triggered by Pin33 that holds the EN line low for as long as it takes to do a proper board reset might be a better solution. It would help to know what the real differences in ESP32 state are between a umachine.reset() and a EN (board reset). |
Beta Was this translation helpful? Give feedback.
-
At a second thought, maybe the machine.reset() code forces a WDT reset. Some ports do that. That is close to a power cycle. |
Beta Was this translation helpful? Give feedback.
-
Recently I was made aware that a machine.reset() does not actually reset some or all of the hardware. Doing a CTRL-D at the REPL in rshell is not the same as pushing the EN button on the ESP32 DevKitC dev boards.
A solution requires a bit of hardware:
Be careful which pin you use to drive this POWERON_RESET transistor. Because pin14 was in the vicinity I choose that ... bad choice! After several hours trying to hack a solution Google revealed at:
https://www.engineersgarage.com/micropython-esp8266-esp32-digital-input-output-pin-class/
that some pins available do funny things during boot. Pins 14, 5 and 15 apparently should be avoided.
Here is a test script. One CRTL-C in rshell after 5 seconds will do a POWERON_RESET, a 2nd CTRL-C within 5 seconds gets you back to REPL.
P.S. It also might be a good idea to slow the response of this circuit down as who knows what the state of any GPIO is during boot. I changed the 1K to 10K and added a 10uF on the base to ground. It now takes about 0.1seconds to do a poweron_reset.
There are several places in my programs where I would do a machine.reset() if things went wrong, maybe having the hardware in an unknown state may have been caused more problems.
Beta Was this translation helpful? Give feedback.
All reactions