Skip to content
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

Report watchdog or other unexpected reboots via the new analytics hook #61

Closed
geeksville opened this issue Mar 25, 2020 · 8 comments
Closed
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@geeksville
Copy link
Member

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.

@geeksville geeksville added enhancement New feature or request good first issue Good for newcomers labels Mar 25, 2020
@BeardyWalrus
Copy link
Contributor

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

esp8266/Arduino#1152

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

@geeksville
Copy link
Member Author

geeksville commented Jun 16, 2020

@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
Copy link

ScriptBlock commented Jul 13, 2020

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
Copy link
Member Author

geeksville commented Jul 13, 2020

@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
Copy link

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
Copy link

ScriptBlock commented Jul 14, 2020

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
Copy link
Member Author

geeksville commented Jul 14, 2020 via email

mc-hamster added a commit that referenced this issue Jan 20, 2021
Merge pull request #648 from mc-hamster/master
@garthvh
Copy link
Member

garthvh commented Aug 14, 2022

Is this fixed by pull #648 @mc-hamster

@thebentern thebentern closed this as not planned Won't fix, can't repro, duplicate, stale Oct 17, 2022
rickmark pushed a commit to rickmark/meshtastic-firmware that referenced this issue Dec 26, 2024
Add mqtt username and password to user preferences
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

5 participants