Release blocker: eliminate ESP32-P4 START timing misses

[masarray]

Release blocker

Physical RC2 on ESP32-P4 E8F60AE0C53F reproduced deterministic START misses and misleading telemetry windows against frozen candidate ed46f3bed73d398d71be2eacf34c4995325c3cad.

Evidence:

• first complete diagnostic: READY and all functional operations PASS, retained telemetry rejected with fpsMin=400, fpsMax=4400, missed=80, TX fail=0;
• direct serial repro after START: first bucket samples=3200, missed=37; later steady buckets 4000, missed=0;
• independent capture: 51.39 s steady canonical segment, 205,562 packets, 3999.94 fps, zero counter gaps, 51 wraps, zero capture drops.

Root cause

The publisher enables the 250 us GPTimer and then formats the PROFILE-armed log. ISR notifications accumulate while formatting, so the first publisher iteration begins with pending_ticks > 1 and skips counters. Separately, telemetry labels quantized samples collected by an asynchronously delayed task as a one-second fps value.

Minimum fix

• make GPTimer start the final START-branch operation after preparation/logging;
• maintain a compile-time lock-free 32-bit sample tick counter and normalize reported fps by elapsed microseconds;
• retain the first partial bucket's missed/TX evidence while using it only as the rate baseline;
• add an ESP32-P4 source-policy regression;
• declare both changed paths in the freeze exception ledger.

No Studio, protocol profile, wire layout, dataset, synchronization policy, or release baseline is changed.

Required verification

• ESP32-P4 firmware build and new boundary policy;
• exact-head full release/Qt/RC2/security/core gates;
• real board 10x Start/Stop with first smpCnt=0, missed=0, TX fail=0;

• =3600 s retained 3999..4001 fps soak;

• independent capture for continuous smpCnt, wraps, frozen wire identity/layout, and smpSynch=0.

Tracks #83. Keep draft and do not move the freeze baseline until all gates and affected physical acceptance pass.

[masarray]

Physical blocker diagnostic on ESP32-P4 rev 1.3 / COM15 (device E8F60AE0C53F), 2026-09-15 Asia/Jakarta.

Artifact provenance:

• Workflow run 34903279584: success
• Artifact 10371831272 outer SHA-256: d68d777345ef96d2e8a6cca9a4c2e2cb2ffc19b9befacef320eb96e075e5da2f
• Manifest sourceCommit: e5cace4bdb930333a6c394343e33e2e9c697da3d (GitHub PR Release blocker: eliminate ESP32-P4 START timing misses #92 merge ref; head parent acd81524d59bd670f1ea2805ac755f5c1f34d6d5)
• Firmware image SHA-256: 4d95807bbe7336a919375dd697c6361df8668ba72233ad007dd7309f8a4746a5
• Flash readback MD5 matched image: 1b5f9e013838c3eb946e418cb86d7dbc

Focused START reproduction after flash:

• first reported normalized rate: ~4000 fps
• missed=0
• canonical tx fail=0
• diagnostic mirror tx fail=0

60-second board-runner diagnostic:

• telemetry windows: 88
• fpsMin=4000, fpsMax=4000
• missed=0, txFailures=0, automaticStarts=0, healthReconnects=0
• Start/Stop 10/10
• deploy readiness, live magnitude/phase/frequency/quality, zero, CT saturation, profile resync, and generation checks all passed

Wire capture:

• 481,542 packets over 77.1822754 s on ASUS_LAN
• canonical first frame after START: smpCnt=0
• dst 01:0c:cd:04:00:01, VLAN 0/PCP4, APPID 0x4000, noASDU=1, svID=ARSTACK_SV01, confRev=1, smpSynch=0, frameLen=128
• longest canonical segment: 232,782 packets / 58.20 s / 3999.90 fps / 0 continuity gaps
• pcap SHA-256: c3c59d2fe694fc3ba3d301103b15fe45592de6386bedfb8133b2cad13b3bc51d
• runner JSON SHA-256: d603d376c824ec889613dd3c34d5c264b219cbe72ebc90246242ed2dd50d16bc

This is blocker diagnostic evidence only, not final RC acceptance. The runner correctly marks diagnosticOnly=true; the required one-hour soak, Studio UI observations, recovery/unplug/replug, wrong-device rejection, and exact frozen-candidate provenance remain open. Do not move the frozen baseline from ed46f3bed73d398d71be2eacf34c4995325c3cad based on this comment.

[masarray]

Physical acceptance checkpoint — 2026-09-15 Asia/Jakarta

Current GitHub/code state:

• blocker head acd81524d59bd670f1ea2805ac755f5c1f34d6d5 is pushed
• all 11 pull-request workflow runs are completed/success
• exact CI firmware artifact and 60-second board/wire diagnostic are documented in the preceding PR comment

One-hour attempt is NOT accepted:

• runner progressed cleanly through 10/10 Start/Stop and checkpoints 60..2520 seconds, each at 4000 fps / missed=0 / txFail=0
• Windows entered Modern Standby at 05:50:17 and exited at 08:31:18
• USB CH343 VID 1A86 PID 55D3 was re-enumerated/port-cycled on resume
• runner failed closed with Final STOP failed after retained soak.
• captured evidence reported wall duration 9768 s and fpsMin 3382, therefore it is invalid for the required uninterrupted 3600-second gate
• board recovered healthy and STOPPED after resume; semantic identity remained device E8F60AE0C53F and boot_id changed, consistent with USB/device reset

Disposition:

• retain this as negative environmental evidence
• repeat the full board soak with an explicit Windows execution-state assertion preventing automatic sleep
• PR remains Draft/open/unmerged
• frozen baseline remains ed46f3bed73d398d71be2eacf34c4995325c3cad
• public release remains blocked until uninterrupted RC2 and mandatory RC1/final verifier evidence PASS

No physical PASS, merge, tag, or public release is claimed by this checkpoint.