You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The built-in postmortem logging has been very useful. However, the data is always output to UART0, which functionally means that I need to be physically connected to the ESP to get that data. More and more, I'm wanting to get this information from a device in the field which has nothing attached to UART0.
I'm not entirely sure the best way to do this yet - among the options I've considered:
Copy the crash information (rst_info, sp, the stack contents, etc) to flash before restarting, and then process as desired at next start up. My biggest worry about this is that we might do too many flash writes to a single sector, especially if the device gets into a tight crash loop.
Send the info somewhere else, e.g. a quick UDP transmit. I've not tried this yet, so I don't know if it's feasible.
Regardless of the specific implementation, I could do it myself if I could register my own callback for when a crash occurs.
The text was updated successfully, but these errors were encountered:
We're already using ESP.getResetInfo(), but aside from the missing stack trace (which has been very useful for me), ESP.getResetInfo() doesn't give us anything for Exceptions or Soft WDT resets, at least for the Huzzah boards we're using. Essentially, I can only use ESP.getResetInfo() right now to find out if there was a hard wdt reset.
The built-in postmortem logging has been very useful. However, the data is always output to UART0, which functionally means that I need to be physically connected to the ESP to get that data. More and more, I'm wanting to get this information from a device in the field which has nothing attached to UART0.
I'm not entirely sure the best way to do this yet - among the options I've considered:
rst_info
,sp
, the stack contents, etc) to flash before restarting, and then process as desired at next start up. My biggest worry about this is that we might do too many flash writes to a single sector, especially if the device gets into a tight crash loop.Regardless of the specific implementation, I could do it myself if I could register my own callback for when a crash occurs.
The text was updated successfully, but these errors were encountered: