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

firmware crash #110

Closed
hartytp opened this issue Dec 21, 2020 · 7 comments · Fixed by #114
Closed

firmware crash #110

hartytp opened this issue Dec 21, 2020 · 7 comments · Fixed by #114
Assignees
Labels
bug Something isn't working
Milestone

Comments

@hartytp
Copy link

hartytp commented Dec 21, 2020

I believe I just saw a firmware crash/watchdog timeout/whatever. I had yellow and green LEDs on for all channels. I pressed the interlock reset button and all LEDs turned off and the fans came on to max briefly.

Are there any logs / debugging tools I should use to narrow this down? Or is this likely to just be another watchdog issue (maybe the timings are marginal during interlock resets?)

@ryan-summers ryan-summers added the bug Something isn't working label Dec 28, 2020
@ryan-summers ryan-summers self-assigned this Dec 28, 2020
@ryan-summers
Copy link
Member

ryan-summers commented Dec 28, 2020

Related to #93 - we do not yet have any crash/reset post-mortem/persistent logging implementation to help with this, but I would really like to add it.

One of the difficulties is the lack of a (larger) external non-volatile memory for storing logs in, which limits our logging capabilities to internal flash or RAM. I'll have to give some thought into a good design here.

@hartytp
Copy link
Author

hartytp commented Dec 28, 2020

It's been a while since I looked at this, but isn't it possible to read out whether the watchdog tripped at boot and just go into an error state instead of starting up normally? That at least gives some level of visibility over the issue.

@ryan-summers
Copy link
Member

It's been a while since I looked at this, but isn't it possible to read out whether the watchdog tripped at boot and just go into an error state instead of starting up normally? That at least gives some level of visibility over the issue.

Yes, and I believe we already currently check and reset the necessary bits, we just don't transition to an error state (although I have other projects where the firmware transitions into "service mode", where it remains not operational for safety reasons) - that may be appropriate here, although would require further design.

@hartytp
Copy link
Author

hartytp commented Dec 28, 2020

okay. Well, I know that time is limited here, so I'm not insisting on any of this. Hopefully the new release will remove the crashes and this won't be so important.

@jordens
Copy link
Member

jordens commented Jan 4, 2021

@hartytp which firmware version and release/debug was this? I.e. is it known to be distinct from #94?

@jordens jordens added this to the 0.2 milestone Jan 4, 2021
@hartytp
Copy link
Author

hartytp commented Jan 4, 2021

Current release binaries. It is not known to be distinct from 94 (which is what I was trying to imply in the initial post).

@hartytp
Copy link
Author

hartytp commented Jan 5, 2021

let's assume this is a duplicate of #94 for now

@hartytp hartytp closed this as completed Jan 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants