tinyusb.git, branch worktree-ch569-hydrausb3

ch32h417: make usbss_phy_cfg return void (unused read-back)

2026-07-11T22:33:00Z

PVS-Studio (V530) flagged the discarded return value of usbss_phy_cfg at every call site. The PHY back-door read-back is only a strobe; the value is never used (matching the WCH EVT demo), so return void. PVS found no other issues in either CH32H417 dcd. Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_01QWhrtHjbSVMKcY68vxBwBm

ch32h417: fix USB3 fallback storm, SET_ADDRESS deref, status-stage completion

2026-07-11T22:28:49Z

Apply correctness-review findings on the USBSS SuperSpeed dcd (still pre-hardware): - Critical: the LINK DISABLE fallback path left TIM12 running, so once the driver switched to USB2 (where the ISR routes to the USB2 handler and never clears the timer flag) the update flag stormed the CPU. Both fallback entry points now go through fallback_to_usb2(), which stops TIM12 first. - Critical: dcd_set_address in fallback mode called ch32h417_usb2_edpt0_status_complete with a NULL request (dereferenced immediately) and fell through into the USB3 path. It now arms the USB2 status ZLP and returns; the address is applied by the USB2 status-complete callback usbd invokes with the real request. - Major: the control STATUS stage (USBSS_UDIF_STATUS) never completed the queued zero-length status transfer, so usbd's status-stage callback never ran and EP0 stayed busy. The status ZLP does not raise a UIF_TRANSFER on this controller, so it is now completed in the UDIF_STATUS branch (and handle_ep0_in no longer completes a zero-length IN early). - Also: LINK_STATE_INACTIVE now counts toward the fallback attempt limit (matches the file header and the vendor), the LINK_CFG init uses LINK_TX_DEEMPH_MASK exactly like the WCH EVT literal, and a dead if/else in the EP0-OUT arm path is collapsed. Build-verified: both full example matrices (SPEED=super and =high) build 20/20. Remaining review notes (U1/U2/U3 PHY low-power reconfig, RECOVERY case, SET_ISOCH_ DELAY -> LINK_ISO_DLY, OUT-DMA clamp) are deferred to hardware bring-up. Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_01QWhrtHjbSVMKcY68vxBwBm

ch32h417: fix USBHS EP0 SETUP re-detect, EP0-OUT toggle, SOF dispatch

2026-07-11T22:20:17Z

Apply correctness-review findings on the USB2 HS dcd (still pre-hardware): - EP0 control OUT arming now writes the full UEP0_RX_CTRL byte (DATA1|ACK) instead of a read-modify-write, so RB_UEP_R_SETUP_IS is cleared - otherwise the data/ status OUT following a SETUP would be re-detected as a new SETUP and every control transfer after the first would break. The SETUP handler likewise writes full TX/RX bytes. This also fixes the missing DATA1 expected-toggle on a control-write data stage. - Add the SOF interrupt branch (USBHS_UDIF_RX_SOF is a top-level INT_FG bit on this IP, not an INT_ST token): dcd_sof_enable() armed SOF but the ISR dropped it, so dcd_event_sof() was never delivered. - Drop the extra INT_FG=USBHS_UDIF_TRANSFER write: the vendor acknowledges a transfer solely by clearing the per-endpoint DONE bit; the aggregate write could clear a second endpoint's still-pending completion (only one is serviced per IRQ). Build-verified (SPEED=high links). Hardware validation still pending. Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_01QWhrtHjbSVMKcY68vxBwBm

ch32h417: register in CI matrix, lwIP throughput, docs and presets

2026-07-11T22:02:59Z

Final integration for the CH32H417 port. - .github/workflows/ci_set_matrix.py: add ch32h417 (riscv-gcc) so CI builds it. - examples/device/net_lwip_webserver: enable LWIP_HIGH_THROUGHPUT for the H417 (SuperSpeed iperf). - docs/reference/{boards,dependencies}.rst + hw/bsp/BoardPresets.json: regenerated for the new board and dependency. usbtest quirks intentionally left at 0 for the H417: its endpoint engine fixes the two CH569 5 Gbps silicon limitations (RB_EP_TX/RX_HALT gives a repeatable STALL for case 13; the reworked EP0/chain path is expected free of the wLength%4==1 ctrl_out drop), so the H417 targets a full 30/30 at SuperSpeed rather than 27/27. The HIL entry (test/hil/tinyusb.json) is deliberately deferred: it needs the chip's ESIG unique id read from the board on first flash, which is pending hardware access. Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_01QWhrtHjbSVMKcY68vxBwBm

ch32h417: add USB3 SuperSpeed dcd with runtime USB2 fallback

2026-07-11T21:59:21Z

Second stage: the USBSS SuperSpeed device driver (SPEED=super now links). The LINK layer is the same IP as the CH569 but the endpoint engine is the H417's reworked chain-DMA design (hardware SEQ_AUTO/ERDY_AUTO, persistent RB_EP_*_HALT, per-chain completion). The RCC/PHY/LINK bring-up and EP0 control sequences are transcribed from the WCH EVT USBSS device demo; data endpoints arm one chain per packet (burst 1) for correctness-first bring-up, matching the CH569 port's initial path - raise CFG_TUD_WCH_USB30_MAX_BURST once the hardware validates. Buffers may live anywhere in the shared SRAM (all DMA-reachable), so no bounce machinery is needed. - src/portable/wch/dcd_ch32h417_usb30.c (+ ch32h417_usb30_reg.h): full dcd with a STATE_CHG-driven LTSSM handler, LMP PORT_CAP/PORT_CFG exchange, EP0 DPH/ERDY flow with software sequence, chain-armed data endpoints, per-EP HALT stall, and a TIM12-backstopped runtime USB2 fallback that hands rhport 0 to ch32h417_usb2_* when SuperSpeed training fails (host has no SS port). - examples/device/*/skip.txt: add mcu:CH32H417 to the FreeRTOS + audio/video examples (no FreeRTOSConfig for this family yet), mirroring mcu:CH569. Build-verified: all 20 device examples build for SPEED=super, and cdc_msc for SPEED=high, clean under -Werror (riscv-none-elf-gcc 13.2). Hardware bring-up at 5 Gbps (usbtest battery, throughput) is pending rig availability. Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_01QWhrtHjbSVMKcY68vxBwBm

Add WCH CH32H417 family + nanoCH32H417 board (BSP + USB2 HS dcd)

2026-07-11T21:50:23Z

First stage of the CH32H417/CH32H416 SuperSpeed port (the second WCH SuperSpeed device family after CH569). This lands the family scaffolding and the USB2.0 high-speed device driver; the USB3 dcd is a stub for now (SPEED=super does not link yet). - tools/get_deps.py, src/tusb_option.h (OPT_MCU_CH32H417 2260 + CH32H416 alias): openwch/ch32h417 SDK dependency. - src/common/tusb_mcu.h: OPT_MCU_CH32H417 block with distinct USB IP tokens (TUP_USBIP_WCH_USB30_H417 / _USBHS_H417) so neither the CH569 nor the CH32V307 drivers match; SPEED=super|high selectors mirror the CH569 port; EP0 = 512 on SS. - hw/bsp/ch32h417: family runs entirely on the V3F core (core 0, boot core), single image in the 512 KB shared SRAM (the only SRAM on the bus matrix, USB-DMA reachable). family.c aliases USBSS/USBSS_LINK/USBHS(/TIM12) to one forwarder (the CH569 LTO identical-code-folding hazard applies), SysTick0 tick, USART1 PA9 debug, ESIG unique id. Linker derived from the EVT V3F script. Board nanoCH32H417 (MuseLab): green LED PC2 active-low, WCH-LinkE VCP on USART1. - src/portable/wch/dcd_ch32h417_usbhs.c (+ ch32h417_usbhs_reg.h, dcd_ch32h417.h): USB2.0 HS dcd for the H417 USBHS IP (per-EP INT_ST EP_DIR+EP_ID, SETUP_IS flag, DONE flags, split UEP_TX/RX_EN, NAK/STALL/ACK encoding, manual toggle). Core exposed as ch32h417_usb2_* internals for the upcoming USB3 runtime fallback; no RAMX bounce (all shared SRAM is DMA-capable, unlike CH56x). Build-verified: board_test and cdc_msc SPEED=high link cleanly under the full -Werror set (riscv-none-elf-gcc 13.2). Hardware bring-up pending (see next). Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_01QWhrtHjbSVMKcY68vxBwBm

hil: update hydrausb3_v1 flasher probe uid (WCH-Link swapped)

2026-07-09T07:34:16Z

Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_019MRGjBT2NBkCoWwyDT4LaE

usbtest: skip silicon-impossible cases via bcdDevice quirk flags

2026-07-09T07:34:13Z

The CH569 USBSS ctrl_out flakiness (cases 14/21, host -EPROTO) is a silicon erratum, not a driver bug: EP0 OUT data stages whose wLength % 4 == 1 are intermittently dropped at 5 Gbps. Proven by A/B against WCH's own binary USB3 stack (SimulateCDC EVT demo patched to accept the gadget-zero 0x5b/0x5c requests), which fails identically on the same board — independent of host LPM (persists with U1/U2 disabled) and sysclk (80 vs 120 MHz). Bulk OUT at the same lengths is clean. Document the erratum in the dcd and drop the ineffective zeroed-BOS workaround. Rather than letting known-impossible cases flake the battery, the firmware now advertises quirk flags in bcdDevice bits 4-7 (tier stays in bits 0-3): 0x10 skips ctrl_out 14/21, 0x20 skips ep-halt 13 (the previously proven single-STALL limitation). usbtest.py skips flagged cases visibly at SuperSpeed only (explicit --tests still runs them) and reports them in the summary/JSON. Also fix the CH56x USB3 dcd leaving an endpoint halted across reconfiguration: clear the stalled flag in dcd_edpt_open/close/ close_all (USB 2.0 9.4.5) so a SET_CONFIGURATION recovery of a halted-then-reopened endpoint does not STALL forever. Validated on hydrausb3_v1 at 5000M: tier-4 battery x3 = 27/27 passed + 3 skipped, full HIL device suite 12/12 green (MSC 160/134 MB/s). Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_019MRGjBT2NBkCoWwyDT4LaE

Harden the CH56x USB3 EP0 control flow

2026-07-08T07:04:14Z

Improvements from chasing the intermittent usbtest ctrl_out failure (cases 14/21) at SuperSpeed: - Process a latched status-stage completion before a simultaneously latched SETUP: with back-to-back control transfers both flags can arrive in one ISR pass and taking the SETUP first dropped the previous transfer's completion inside usbd - Status completion is recognized from either event side via a shared helper (_ep0_status_pending), and the status arm keeps both directions armed - hardware-verified that the RX engine must acknowledge the STATUS TP even for an IN status (RX unarmed makes SET_ADDRESS time out) - EP0 idles ACK-armed and an OUT data packet that lands before usbd arms the stage is held (_ep0_early_len) and delivered at arm time; the ERDY for a host-to-device data stage is signalled from the SETUP ISR (matching the reference flow) instead of only ~100 us later from task context - EP0-OUT data arms OR into RX_CTRL, preserving the live packet sequence bits like the reference's USB30_OUT_Set Known issue (documented for future work): ctrl_out remains flaky at SuperSpeed with a ~0.3% per-transfer failure rate (EPROTO on the host). Exhaustively characterized on hardware: the device receives the SETUP exactly once and arms correctly (post-arm RX_CTRL/DMA/LINK_STATUS identical to passing iterations, verified by ISR-time tracing), then the host's data DP never arrives; bulk OUT at identical sizes is error-free, host LPM off makes no difference, and neither NRDY holds, double ERDY, sequence preservation nor removing the iso endpoints change the rate. Root-causing needs a USB3 protocol analyzer or WCH silicon documentation. High speed is unaffected (30/30). Battery results with this commit: 30/30 high speed, 29/30 SuperSpeed (case 13 halt = documented silicon limitation, cases 14/21 pass most rounds). Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_019MRGjBT2NBkCoWwyDT4LaE

Add SuperSpeed isochronous support to the CH56x USB3 dcd

2026-07-08T05:26:08Z

The register model comes from disassembling WCH's official USB30 device blob (libCH56x_USB30_device_lib.a): USB30_ISO_Setendp reveals per- endpoint isochronous mode bits in UEP_CFG (bit 16+ep for OUT, bit 24+ep for IN); arming and completion then use the normal endpoint flow. The usbtest example moves back to tier 4 at SuperSpeed with an iso pair in the SS descriptor set - all four kernel usbtest iso cases (15/16/22/23) pass on hardware at 5000M. The endpoint-halt latch from the previous commit is kept (it fixes usbtest case 29); case 13 is now documented as a silicon limitation after exhaustive on-hardware experiments: a halted endpoint answers exactly one probe with a STALL TP and no re-arm strategy (any NUMP, ERDY, 30 us timer re-assertion, endpoint enable bounce) revives it - no event fires per stall TP. The CH32H417's reworked endpoint engine adds a persistent RB_EP_TX_HALT mode, evidently addressing exactly this. Battery results: 30/30 at high speed, 28/30 at SuperSpeed (case 13 = silicon halt limitation; case 14 ctrl_out is intermittent - pre-existing EP0 OUT flakiness under investigation). Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_019MRGjBT2NBkCoWwyDT4LaE