Skip to content

docs(ch32v): console-output decision + verified wlink probe operations (#1208) - #1211

Merged
zackees merged 1 commit into
mainfrom
docs/1208-ch32v-console-and-probe-ops
Jul 29, 2026
Merged

docs(ch32v): console-output decision + verified wlink probe operations (#1208)#1211
zackees merged 1 commit into
mainfrom
docs/1208-ch32v-console-and-probe-ops

Conversation

@zackees

@zackees zackees commented Jul 29, 2026

Copy link
Copy Markdown
Member

Closes the last software-reachable Phase 3 item from #1208"decide and document the SDI-print / serial story" — and corrects probe guidance against wlink v0.1.2's actual behaviour.

Console output on a part with no USB

CH32V003 has no USB peripheral, so there is no target-side CDC port for fbuild monitor to open. Two real options, documented with a recommendation rather than a survey:

SDI-print over the debug link (recommended)wlink sdi-print enable. Carries a virtual serial channel over the same single-wire SWIO connection used for flashing, so it costs no extra pin and no USART peripheral. That matters concretely: Phase 1 measured a bare blink at RAM 1180 / 2048 B, leaving ~868 bytes, and a USART driver plus buffers is real budget against that.

Caveats that keep it from being a drop-in, all documented:

  • enable implies --no-detach, so it holds the chip attached and conflicts with flashing on the same probe — print and flash must be sequenced.
  • It is a debug-module channel, not a UART: no baud, no DTR/RTS, so docs/usb-cdc-control-line-matrix.md does not govern it.
  • It is not wired into fbuild monitor. Integrating it would mean teaching the serial layer about a non-serial transport — larger than this bring-up.

USART to an external bridge — the fallback, for when SDI-print's attach behaviour gets in the way or the console must survive without the probe.

Probe operations — each verified against installed wlink v0.1.2

Software mode switch. wlink mode-switch --rv works without touching the probe. The README I wrote in #1210 described button-hold as the only route; it is really the fallback for when wlink cannot reach the probe yet (wrong mode + no driver bound is the chicken-and-egg). Corrected.

Target power. wlink set-power enable3v3 powers the target off the probe — no external supply needed for a bare V003.

list is a false-negative trap. With no probe attached:

Command Exit Output
wlink status 1 Error: WCH-Link not found, please check your connection
wlink flash <file> 1 Error: WCH-Link not found, please check your connection
wlink list 0 (nothing)

A presence check built on list would read exit 0 as success. Presence must key off status. The Phase 0 test already uses status; this documents why so it doesn't get "simplified" later.

The non-zero exit on flash is also the reason WlinkDeployer's result.success() is trustworthy — there is no path where a missing probe is reported as a successful flash.

Test plan

  • soldr cargo test -p fbuild-deploy --lib wlink:: → 1 passed, 3 ignored (hardware/network-gated), 0 failed
  • soldr cargo clippy -p fbuild-deploy --all-targets -- -D warnings → clean
  • soldr cargo fmt --all
  • Every wlink behaviour claim above was executed against the installed v0.1.2 binary, not read from docs

Docs-only apart from the test doc-comment. Refs #1208.

🤖 Generated with Claude Code

#1208)

Closes the last software-reachable Phase 3 item from #1208 — "decide and
document the SDI-print / serial story" — and corrects probe guidance
against wlink v0.1.2's actual behaviour.

Console output. CH32V003 has no USB peripheral, so there is no target CDC
port for `fbuild monitor` to open. Documents the two real options and
recommends SDI-print over the debug link (`wlink sdi-print enable`),
since it needs no extra pin and no USART — which matters when a bare
blink already leaves only ~868 bytes of SRAM. Records the caveats that
make it not a drop-in: `enable` implies `--no-detach` so it conflicts
with flashing on the same probe, it is a debug-module channel with no
baud/DTR/RTS (so the control-line matrix does not govern it), and it is
not wired into `fbuild monitor` today. The USART-to-external-bridge
alternative is documented as the fallback.

Probe operations, each verified against the installed wlink v0.1.2:

- Mode switching is available in software (`wlink mode-switch --rv`).
  The README previously described the button-hold as the only route; it
  is really the fallback for when wlink cannot reach the probe yet.
- `wlink set-power enable3v3` powers the target from the probe.
- `wlink list` exits **0 and prints nothing** with no probe attached,
  while `status` and `flash` exit 1. Presence checks must use `status`;
  `list` cannot distinguish "no probe" from success. The non-zero exit
  on `flash` is also why WlinkDeployer's `result.success()` cannot report
  a missing probe as a successful flash.

Also records the Phase 1 measured footprint (flash 8896/16384, RAM
1180/2048) next to the memory notes, since that headroom is what drives
the console recommendation.

Co-Authored-By: Claude <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Jul 29, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@zackees, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 50 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: fd411881-b488-4582-8307-8ec5fdd24eac

📥 Commits

Reviewing files that changed from the base of the PR and between 4544faa and fa378f2.

📒 Files selected for processing (2)
  • crates/fbuild-build-mcu/src/ch32v/README.md
  • crates/fbuild-deploy/src/wlink.rs

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@zackees
zackees merged commit e7c594a into main Jul 29, 2026
87 of 93 checks passed
@zackees
zackees deleted the docs/1208-ch32v-console-and-probe-ops branch July 29, 2026 00:44
@fastled-project-sync fastled-project-sync Bot moved this to Triage in FastLED Tracker Jul 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Triage

Development

Successfully merging this pull request may close these issues.

1 participant