Reboot after crash

[ernitron]

Question : Is there a way to make a soft reboot after crashing from code instead to get back to interpreter?
This is the mode how NodeMCU works and I find very useful. If anything in the code gets wrong (memory allocation, uncatched errors,..) the unit just reboots

Should I use something like this in the main.py or boot.py (?)

Code: Select all

   
try:
    main_code_here()
except:
    import machine
    machine.reset()

I use uPython v1.8.3-13-g0be4a77-dirty on WeMos.

I am really sorry if I miss this issue in the documentation as I read a lot but couldn't find this information anywhere

[deshipu]

The ESP8266 does restart after crashing, you don't need to do anything for that to happen. If you want it to restart after encountering an unexcpected exception in your code though, then yes, the approach you show would be the correct one, except you really don't want to have a ""naked" "except:" there, do "except Exception:", because not everything that can be caught is a proper exception, and you don't want to catch things like KeyboardInterrupt.

[ernitron]

Thank you for your answer.

Well, I was expecting that after an out of memory failure it would reboot but it doesn't. Think of a deployment where there are many unattended devices and they hang waiting for user intervention. Not really a IoT thing, I guess. Getting back to interpreter and waiting for input is a development behavior, IMHO.

NodeMCU just panics and reboots. This saved me in many situations. I think it should be implemented in the VM rather than in the application. It could be set as an option. Something like:

Code: Select all

import machine
machine.reboot_on_crash()

What Pfalcon and Damien think about this?

[pythoncoder]

In general to implement such a feature you need a hardware watchdog timer: if the 'crash' is caused by code going into an infinite loop, no exception will be thrown. The chip used on the Pyboard has such hardware, but as far as I know the ESP8266 doesn't and external hardware would be required.

[ernitron]

Maybe I look at this thing from an application developer pov and not from a core-developer. I will study more the internals but actually will go beyond my scope... anyway I like uPython and eager to contribute (positively I hope).

@pythoncoder: An infinite loop is not a crash It will not generate any exception and is not what I am asking. I am just saying that the behavior on Exception COULD (not MUST) be a reboot instead to get back to interpreter waiting for user input. This is what NodeMCU does. therefore I assume it will be possible (not saying easy) in uPython.

The exceptions are:
- Out Of Memory: even in micropython is possible to have leaks
- Any code/math/name/ I/O errors etc exceptions: still possible to have bugs in production code And I found more easy to handle them rebooting rather than considering all possible exceptions. Resources are very scarce on ESP and more code for exceptions means less code for application.

Pfalcon could add something about this subject? Or should I go for the core-development forum for this discussion?

Thanks in advance

PS: I am perfectly aware that a very bad loop can deflagrate in a bad coded application: a very short cycle of run-exception-reboot. Again this is bad coding but a reboot in production is better than an infinite hang. This is my experience as a developer.

[deshipu]

I think that what you are proposing would make debugging a hell, so I'm not sure it should be encouraged (the Zen of Python says: Errors should never pass silently). However, you can do it already -- by catching the exception -- so I don't quite understand why you are requesting any changes. How is catching the exception and restarting not suitable for what you want? It seems to me it does exactly what you need, and on top of that, you can even add a condition there, so that, for instance, when a button is held it doesn't restart and lets you debug your program. And you can even specify which exceptions should result in a restart and which not. I think it's already much better than what you are proposing.

[deshipu]

By the way, if you are afraid of your program getting stuck in an infinite loop, there is also a solution for that: http://micropython.org/resources/docs/e ... e.WDT.html

[ernitron]

Why a debugging hell? I am saying that it should be an explicit call to a method like machine.reboot_on_crash() so nothing will change if not called. The reason I would like to have this feature is that I cannot assume all the exceptions there will be thrown and I would like to catch them all with maybe the exclusion of KeyboardInterrupt or some other kind of exception to make it work along webrepl).

I am profoundly devoted to the sacred Zen Python Principles, I think (and I am also experiencing) that uPython in micro-machines like ESP8266 they will be very hard to follow as the code will be extremely shy and ultimately less robust. Making code and applications more resilient in that tiny environment requires extra efforts (=more time spent on code optimization). This probably is also biased by my attitude for applications in production rather than in perennial state of development. I apologize.

Besides, I am doing exactly what I have said: try: main() except LOT OF CONDITIONS: machine.reset() is working but I found it not very elegant and always with the fear that machine can hang. But at the end you are right: a solution is there and there's no need to add something else.

[deshipu]

You don't need a lot of conditions. Just do:

Code: Select all

try:
    your code here
except Exception:
    log your error and restart

[pythoncoder]

Or perhaps:

Code: Select all

try:
    your code here
except KeyboardInterrupt:
    raise
except Exception:
    log your error and restart