Skip to content

P0 Studio: exact firmware build identity and stage-aware PTP START recovery - #263

Open
masarray wants to merge 23 commits into
fix/p0-flight-recorder-race-timestamp-20261020from
fix/p0-firmware-build-ptp-failure-ux-20261020
Open

masarray wants to merge 23 commits into
fix/p0-flight-recorder-race-timestamp-20261020from
fix/p0-firmware-build-ptp-failure-ux-20261020

Conversation

@masarray

@masarray masarray commented Oct 20, 2026 •

Copy link
Copy Markdown
Owner

Physical feedback / reproduction

User installed PR #262 through Studio. Firmware pane showed semantic version v0.1.1 and Device ready, hiding 16-digit bundled/observed build identifiers. Time Sync then displayed START FAILED, without the reason in GUI. Old capture report c959... predates new verified install and is not a reliable check of the current board identity. Screenshots alone do not prove PHY/MAC cause.

Root findings

  • FirmwareManager and DeviceController already have exact expected/observed build IDs; FirmwarePanel displayed neither. Completion step was based on compatible protocol, not exact matching firmware.

  • Native PTP startup has independently arriving positive role PTP2 and runtime STATUS readbacks. Immediate rejection upon an earlier STOPPED or stale role status is a false negative. Correct behavior must wait for BOTH positive signals within the existing absolute timeout; never fake a lock or skip STOP rollback.

  • All distinct START errors were collapsed into a generic badge. The ESP32-P4 SOURCE already tracks actual Announce, Sync, Follow_Up, and TX failures but failed to report them at readiness timeout.

Implementation

  • UI always displays bundled and observed build ID and exact MATCH/MISMATCH, keeps semantic product version, and fixes misleading bootloader target/reinstall labels.

  • DeviceController retains specific START failure reason plus transaction stage across STOP rollback; native PTP status accepts positive PTP2 and STATUS evidence in either order while remaining bounded/fail-closed.

  • SOURCE firmware logs concrete 4 counters (and readiness flag) ONLY at failed startup. On failed START, Ethernet diagnostics use the SAME ETH_EVENT FreeRTOS event bit already used by the 4kHz publisher to distinguish link DOWN vs link UP/role runtime invalid, with no polling task, no PHY ioctl and no hot-path changes.

  • Time Sync shows concise fault text ONLY when needed; Copy diagnostics includes exact stage and detailed logs. No standalone scripts or external bench kit.

  • Regression structural gates cover exact build UI, bounded runtime proof and single owner Ethernet link diagnostics. PTP SOURCE firmware, Qt, Native Preview, Windows Lifecycle CI must PASS on exact HEAD before artifact.

Not merged to main. Physical PTP TX/relay acceptance is still required; no software-only LOCK claims.

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ⚠️ Failed 2026-10-20T11:06:27.412154Z c9725e7 PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant