fix(desktop): read a booting board as progress, not an error - #13
Merged
Conversation
A board that answers a hello before app_main finishes refuses it with the display startup stage it has reached, and the hello retry timer tries again a second later. Logging that as a device error reads like a contradiction and like a failed flash, which is exactly when it shows up. bsp_display_status is the only pre-handshake source of a display-* code, so those now report the board as still starting up. Every other refusal is untouched. Co-authored-by: Cursor <cursoragent@cursor.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.
A board that answers a hello before
app_mainfinishes refuses it with the display startup stage it has reached, and the hello retry timer tries again a second later. The desktop logged that asDevice error: display-ready, which reads like a contradiction and like a failed flash — and it shows up during the post-flash reconnect, which is exactly when a failed flash would.The CrowPanel starts its protocol tasks before display bring-up on purpose, then sets
system_readyon the last line ofapp_main, afterdeck_ui_inithas restored saved decks from flash. Any hello landing in that window gets refused withbsp_display_status().bsp_display_statusis the only pre-handshake source of adisplay-*code, so those now log asProtocol: board is still starting up (display-panel-init); retrying. Every other refusal, includingunsupported-protocolandinvalid-json, is untouched.Desktop only — no firmware change, no reflash.
Covered by a new test in
desktop/test/device.test.jsthat refuses the first hello with a startup stage and a genuine error, then asserts the two log lines read differently and the session still completes.