feat(ch32v): flash-readback and core-executing verification for Phase 2 (#1208) - #1212
Conversation
… 2 (#1208) `wlink flash` exiting 0 only means the tool accepted the write. Two new hardware-gated tests close the gap between that and "the firmware is actually on the chip and running", so when a probe reaches the bench the automated evidence is real rather than a tool's self-report. - try_verify_flash_readback_ch32v003 — dumps code flash from 0x08000000 and byte-compares against the image, reporting the first differing offset. Catches a partial write, a wrong base address, or write-protected flash; the flash exit code distinguishes none of these. - try_ch32v003_core_is_executing — resumes the MCU and samples registers twice 250ms apart, asserting the state advanced. Distinguishes "flashed but halted / stuck in a fault loop" from "running", which readback alone cannot. Deliberately fails rather than warns on identical samples, since a halted core is a bring-up failure. Both are explicitly documented as proxies, not the Phase 2 milestone: they cannot show the GPIO toggles at the right rate. Only a scope or LED can, and BOARD_STATUS.md stays at compile-verified until someone has watched it. Also documents the ordered bench verification sequence in the CH32V README so the steps run in an order where each rules out a failure the previous one cannot see. Co-Authored-By: Claude <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 45 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
wlink flashexiting 0 only means the tool accepted the write. These two hardware-gated tests close the gap between that and "the firmware is actually on the chip and running", so when a probe reaches the bench the automated evidence is real rather than a tool's self-report.What's added
try_verify_flash_readback_ch32v003— dumps code flash from0x08000000viawlink dumpand byte-compares against the image, reporting the first differing offset. Catches a partial write, a wrong base address, or write-protected flash. The flash exit code distinguishes none of those.try_ch32v003_core_is_executing— resumes the MCU and samples registers twice, 250 ms apart, asserting the state advanced. Distinguishes flashed but halted / stuck in a fault loop from running — something readback alone cannot do. It fails rather than warns on identical samples, because a halted core is a bring-up failure, not a flaky read.What these are not
Both are proxies, not the Phase 2 milestone. A clean run proves the image is on-chip and the CPU is retiring instructions. It says nothing about whether the GPIO toggles at the right rate — only a scope or LED can. Both tests say so in their doc comments and in their passing output, and
docs/BOARD_STATUS.mdstays at compile-verified until someone has actually watched the blink.I'd rather the harness be explicit about that boundary than let a green test suite imply a bring-up that hasn't happened.
Bench sequence
The CH32V README now documents the ordered sequence, where each step rules out a failure the previous one can't see:
status→ build → flash → readback → core-executing → observe blink (manual)Test plan
soldr cargo test -p fbuild-deploy --lib wlink::→ 1 passed, 5 ignored, 0 failedsoldr cargo clippy -p fbuild-deploy --all-targets -- -D warnings→ cleansoldr cargo fmt --allci/audit_ignored_tests.py→ all new#[ignore]reasons carry concrete hardware/network justifications per the process: ignored-test policy + bitrot audit (#826 followup) #839 policywlink dump/regs/resumeargument shapes verified against the installed v0.1.2 binaryCannot be executed here — no probe enumerates on this host (see #1208). Refs #1208.
🤖 Generated with Claude Code