-
Notifications
You must be signed in to change notification settings - Fork 222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
esp-backtrace: Option to reset instead of halting #1586
Comments
True - until now this is mainly meant to help during development. Not really thought about the production use case. I could also think about some additional features like persisting the backtrace and panic/exception information - then the application could optionally send this to a server on next boot |
Persisting is a good idea. To spin it further, I think it should be opt-in, with a user-provided buffer. A bit tricky to use because the buffer needs to be placed in an uninitialized section, but one can then choose how much memory one can sacrifice for something that, in an ideal world would never be used :) |
There are a couple of ways to achieve this behaviour as a work around:
|
Oh look whose issue this is. 👀 We could contribute an esp-hal feature to panic_reset. |
Halting is fine for development, but I can't really expect end-users to grab a pair of tweezers and short a pair of pads in case their device panics. At least not in every one of my projects :)
The text was updated successfully, but these errors were encountered: