feat(serial): detect crash/reset events in board output - #27
Merged
Conversation
The tooling used to watch a board crash-loop and say nothing: during the
first hardware session the chip panicked and rebooted five times while
serial reads cheerfully returned lines as if nothing happened - the only
tell was a duplicated boot banner the caller had to notice themselves. An
agent cannot distinguish "board is quiet" from "board is dead" without
this.
The line scanner now classifies crash signatures as it assembles lines:
reset rst:0x.. (REASON) reason captured as detail
panic Guru Meditation Error following Backtrace: attached as detail
watchdog Task watchdog got triggered / AVR "wdt reset"
brownout Brownout detector was triggered
abort abort() was called
Events (capped at 50) come back on every read/wait_for response - paged
reads only return events newer than `since` - and get_config reports
event_count/last_event. A reset, panic, brownout or abort also resolves any
pending wait_for early with the event attached: the output being waited for
is not coming from a board that just crashed. Watchdog warnings only record,
since they can be transient. clear() drops events; cursors stay monotonic.
Verified on the ESP32-S3 with a crash-on-command sketch driven over MCP:
esp_restart() ended a pending wait with {type:reset, detail:RTC_SW_CPU_RST};
a null-pointer store produced {type:panic, line:"Guru Meditation Error:
Core 1 panic'ed (StoreProhibited)..."} with the real backtrace attached as
detail; abort() recorded and rebooted; the watchdog signature matches the
task_wdt lines captured from this board's actual crash-loop, and benign
lines containing the word "reset" do not false-positive.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Third of the v0.6.0 series (pain point 3: the tooling watched a board crash-loop five times and said nothing).
What changed
The serial line scanner (from #26) now classifies crash signatures:
resetrst:0x… (REASON)panicGuru Meditation ErrorBacktrace:linewatchdogTask watchdog got triggered/ AVRwdt resetbrownoutBrownout detector was triggeredabortabort() was calledread/wait_forresponse (paged reads only return events newer thansince);get_configaddsevent_count/last_event.wait_forearly with the event attached — the awaited output isn't coming from a board that just crashed. Watchdog warnings only record (can be transient).Verified on hardware (ESP32-S3, crash-on-command sketch driven over MCP)
esp_restart()→ pending wait ended with{type: reset, detail: RTC_SW_CPU_RST}{type: panic, line: "Guru Meditation Error: Core 1 panic'ed (StoreProhibited)…"}with the real backtrace attached as detailabort()→ recorded + reboot reset tracked (event_count: 6)task_wdtlines this board printed during its real crash-loop; benign lines containing "reset" do not false-positive🤖 Generated with Claude Code
EOF