Report watchdog or other unexpected reboots via the new analytics hook

[geeksville]

So we can get information from the field to see if there are errors occuring that we don't know about.

This would be done by calling recordCriticalError() from setup() based on reading the reset error reason. Preferably with the address of the fault also.

[BeardyWalrus]

Found this thread which seems to have some similarity to this issue, might help someone get started.

https://github.com/esp8266/Arduino/issues/1152

Not sure what we would do with the stack trace when it gets loaded post-reboot. Any ideas?

[geeksville]

@BeardyWalrus thanks! that's a great link.

There is a "bug report protobuf" which is defined but not yet implemented. Someday it would be ideal if the device code checked for crash reports at boot, if found, squirrel them away. Then later when the phone connects we send it to the phone (and the phone reports it using our Crashlytics reporter). So we could then have great visibility of device crashes in the field (which I bet most of the time aren't even noticed by users) and we can fix the bug. (but that would be a later step after we can just capture it)

[ScriptBlock]

Looks like that thread evolved into a nice little library. Better to try to integrate that library or adapt that code here? Since this library is ESP only, support for NRF52 would need to be separate.

[geeksville]

@ScriptBlock that library looks great. And since it just dumps into a textfile on the filesystem the NRF52 version could be easily compatible.

1. On either platform (initially only ESP32) dump a crash file as "/lastcrash.log"
2. When phone contacts device if a /lastcrash.log file exists send it to the phone inside a series of protobufs (one per line?). After phone has it, delete file.
3. device wise the feature is done.

(Phone can handle opening a crashlytics report with that file)

[ScriptBlock]

Cool - i'll start with the library. I ordered a handful of the ttgo devices today so that I could start testing until the RAKs are more supported.

[ScriptBlock]

When trying to compile with simple integration of that library, I see that it's looking for a reference to user_interface.h. This seems to be an ESP library based file, but doesn't seem to be available in the manner I'm trying. Any thoughts on this?

The declaration in the example ino/cpp looks like

extern "C" {
#include "user_interface.h"
}

I thought you might be immediately familiar with how something like this would be referenced. If not, I'll keep digging. As you might expect, the error looks like this

src/main.cpp:50:28: fatal error: user_interface.h: No such file or directory

or.. in another method

.pio/libdeps/tbeam/EspSaveCrashSpiffs/src/EspSaveCrashSpiffs.h:44:28: fatal error: user_interface.h: No such file or directory

It doesn't seem like a file I would create. The example programs don't have this header defined.

[geeksville]

Sorry alas no idea.

(Sent from a phone - please ignore typos)

On Mon, Jul 13, 2020, 18:04 ScriptBlock [email protected] wrote:

When trying to compile with simple integration of that library, I see that it's looking for a reference to user_interface.h. This seems to be an ESP library based file, but doesn't seem to be available in the manner I'm trying. Any thoughts on this?

The declaration in the example ino/cpp looks like

extern "C" { #include "user_interface.h" }

I thought you might be immediately familiar with how something like this would be referenced. If not, I'll keep digging.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/meshtastic/Meshtastic-device/issues/61#issuecomment-657906654, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXB2MVSEWMCWKUIVUFSELR3OVKBANCNFSM4LTZ7IYA .

[garthvh]

Is this fixed by pull https://github.com/meshtastic/Meshtastic-device/pull/648 @mc-hamster