machine.soft_reset() behaves curiously on esp8266
Hi!
This is related to https://github.com/micropython/micropython/issues/5764
Thanks a lot for implementing it by the way! 😄
If I invoke it from the REPL, everything works as expected, but if it's invoked from a running code, it will drop to REPL (and with no MPY: soft reboot message). Here's an example:
try:
trixie.run()
except KeyboardInterrupt:
trixie.runner.stop()
except trixie.ResetError:
# land here on reset
print('SOFT RESET')
machine.soft_reset()
except trixie.RebootError:
# land here on reboot
print('HARD RESET')
machine.reset()
except Exception as exc:
# we should never end up here
print('EXCEPTION')
trixie.runner.stop()
trixie.run() raises trixie.SoftReset on soft reset intent, after which 'SOFT RESET' is printed, but then it drops to REPL instead.
I saw it in another issue, that it's by design that main.py won't be called on soft-reset, so I tested the snippet above in _boot.py and boot.py also, but it produces the same behavior. Not having 'MPY: soft reset' printed is suspicious. I'm confused if this is indeed a bug, or I'm doing something wrong.
Thanks a lot for looking into this!
Generalizing "soft reboot" feature to cover full reset possibility
pyboard.py uses "soft reboot" feature to provide a clean environment for code execution. run-tests uses it to provide clean environment for each test. It's great to have this feature, without relying on the underlying hardware capabilities for reset (which may be not there, which may have various issues and artifacts, not work as expected, etc.). However, over last time, we faced the limitations of "soft reboot" approach too - e.g., on esp8266 it doesn't reinitialize network stack and other subsystems, which can lead to various problems either.
And as we start to approach automated network testing, e.g. https://github.com/micropython/micropython/issues/3014, that limitation becomes clear and disabling. For example, Zephyr network stack has enough bugs that without resetting it completely between tests, any results not just can, but are skewed.
So, it would be nice to have an option to implement "soft reboot" as "hard reboot". Per the initial paragraph, that would have various issues in general, but if it works in a particular case, why not?
And here we come to the essence of the issue: currently, REPL code relies that if soft reboot was done in raw REPL, then it remains in raw REPL. Of course, this is not attainable with hard reboot, so I'm proposing to change that - after soft reboot, the interpreter comes back with the normal REPL.