Host (hcd_ci_fs.c):
- Release the speculatively-armed sibling BDT on the NAK path (IN only) as
well as on completion, so a NAKed multi-packet IN no longer leaks a BDT
that stays own=1 and blocks every same-direction pipe. Both paths now go
through a single release_sibling_bd() helper (was a copy-pasted disarm).
- Clear the ENTIRE shared BDT (both directions) on bus reset; clearing only
the IN half left a stale OUT/SETUP descriptor after a disconnect mid-OUT,
blocking the first control transfer on re-enumeration.
- Size bda[] to span the whole BDT (2*2*4) so STAT-indexed access is within
the declared array bounds (was out-of-declared-bounds, benign via union).
Shared (ci_fs_type.h):
- Hoist buffer_descriptor_t and the TOK_PID enum out of the device and host
drivers into the shared header so the identical definitions cannot drift.
Board (kinetis_k):
- Drop a redundant local in board_get_unique_id.
Build-verified: host + kinetis k/kl/k32l + MCX. HIL: frdm_k64f host 2/2
(cdc_msc_hid + device_info); frdm_kl25z device core suite green with the
relocated definitions.
- board_uart_read was a stub returning 0, so host examples that bridge the
UART console to a CDC device (echo test) received nothing. Implement it via
an RDRF-interrupt-fed tu_fifo, matching the stm32 family (non-blocking, no
RX overrun). board_uart_write is already non-blocking.
- implement board_get_unique_id() from the SIM 128-bit UID registers so
frdm_k64f/teensy_35 report a real USB serial instead of the fixed default.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ExGPLP5eU43LR7o6yYLpNi
Complete the khci -> chipidea ci_fs migration that was started for device
(commit d70403f1f "host is not yet"):
- device: switch kinetis_k/kl/k32l (Makefiles + k32l CMake) to dcd_ci_fs.c
- host: add hcd_ci_fs.c (port of hcd_khci.c onto ci_fs_regs_t) and switch all
Kinetis families to it; remove src/portable/nxp/khci entirely
- enable host examples (device_info, cdc_msc_hid) for mcu:KINETIS_K
- README: merge the KL and K32L2 rows into a single "KL, K32L" ci_fs row
hcd_ci_fs.c also fixes two pre-existing host bugs found via HIL on frdm_k64f
(present in the old hcd_khci.c too):
- data toggle was flipped on a NAK in suspend_transfer; a NAK transfers no
data so the toggle must be preserved, else the retried bulk packet is
silently discarded by the device (MSC CBW/CSW hang). See comment in file.
- prepare_packets asserted and dropped a transfer when the single shared BDT
was still owned by an in-flight transfer under concurrent activity; now it
returns busy and resume_transfer defers/retries on the next SOF.
HIL verified on frdm_k64f: device 13/13, host cdc_msc_hid (CDC mount + echo +
MSC mount, through a hub).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ExGPLP5eU43LR7o6yYLpNi
Real 128-bit chip UID as the board serial (IAP cmd 58, status checked
against IAP_CMD_SUCCESS), replacing the shared placeholder — required for
HIL board identification by serial. lpc40's lpcopen Chip_IAP_ReadUID()
returns only the first UID word, hence the direct iap_entry() call.
Verified on ea4088_quickstart and lpcxpresso1549: both enumerate with
their chip UID and are selected by it in the HIL configs.
stm32h533nucleo could never link with IAR: family.cmake points LD_FILE_IAR
at linker/stm32h533xx_flash.icf, which did not exist (every sibling H5
variant has one). Surfaced by CircleCI's one-random job picking
stm32h533nucleo+IAR (Fatal error[Lc002]). H533 and H523 have identical
memory maps (512K flash / 272K RAM; their GCC .ld files differ only in a
comment), so the icf is a copy of the H523 one.
- EP0 OUT: park a back-to-back data-stage packet the DCP accepted before
PID could go NAK and deliver it into the next armed chunk; flow-control
the single-buffer control pipe between chunks (usbtest ctrl_out
corruption); discard a packet parked while an OUT pipe was halted so
BOT reset recovery's fresh CBW read can't receive stale WRITE data
- HS UTMI PHY power-up per the FSP sequence, shared by dcd/hcd: CLKSEL
programmed from the board XTAL (EK-RA8M1 runs 20 MHz; the 24 MHz reset
default never locks) while DIRPD holds the PHY down, then timed release
- hw/bsp(ra8m1_ek): fix U60CK divider macro - BSP_CFG_U60CK_DIV used the
generic USB_CLOCK_DIV_8 encoding (7), which USB60CKDIVCR rejects,
leaving the USBHS link domain at 480 MHz; the USB60-specific
BSP_CLOCKS_USB60_CLOCK_DIV_8 (4) sticks and yields the required 60 MHz
from PLL1P
- support FS-only builds on the high-speed port: gate SYSCFG.HSE on
TUD_OPT_HIGH_SPEED (RHPORT_DEVICE_SPEED=OPT_MODE_FULL_SPEED was a
silent no-op) and always compile both hwfifo access widths - the FIFO
width belongs to the module, not the link speed (FS builds corrupted
odd-length tails: 16-bit access against MBW-32)
- iso activate: reset stale pipe bookkeeping so a BRDY firing before the
class re-arms can't replay a pre-SET_INTERFACE transfer; write PIPEBUF
after PIPESEL selects the pipe (PIPESEL-windowed register)
- clear-halt: re-assert BUF on a still-armed OUT pipe (usbtest case 29)
- bound the D0FIFO ready spin so an undrained double-buffered IN pipe
can't freeze the stack with the IRQ masked
- usbtest example: cap interrupt mps at 64 on RUSB2 high speed (pipes
6-9 have a fixed 64-byte buffer, RA6M5 UM 29.1)
Verified: usbtest 30/30 on ra6m5_ek (HS), ra4m1_ek (FS) and ra8m1_ek
(FS-forced build on the HS port).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HeF2gZ1M7GWkz6Av4BpKPg
The BSP family and MCU option were named "ch58x"/"CH58X", but the supported part is
the CH583/CH582 (and the SDK repo is openwch/ch583); CH585 is a separate MCU family,
so the CH58x umbrella was misleading. Rename to the specific family:
- hw/bsp/ch58x -> hw/bsp/ch583 (dir), and the BSP-local files ch58x_it.* ->
ch583_it.*, system_ch58x.* -> system_ch583.* (include guards/refs updated). The
vendor SDK files (CH58x_common.h, CH58x_*.c in hw/mcu/wch/ch583) keep their names.
- OPT_MCU_CH58X -> OPT_MCU_CH583 in tusb_option.h, tusb_mcu.h, and the shared WCH
USBFS driver (ch32_usbfs_reg.h, dcd_ch32_usbfs.c). OPT_MCU_CH582 is kept as an
alias (same value), so either name selects the same code.
- FAMILY_MCUS CH58X -> CH583, CFG_TUSB_MCU=OPT_MCU_CH583, mcu:CH58X -> mcu:CH583 in
the example skip lists, the CI build matrix (ci_set_matrix.py), the get_deps family
tag, and docs/reference/boards.rst.
Board names (ch582m_evt, yd-ch582m) are unchanged. Verified: make + cmake build for
ch582m_evt, and ci.lan HIL (all device examples pass).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Fold in the CH58x BSP review fixes:
- family.mk: drop stray trailing backslashes on the last LDFLAGS/SRC_C entries
(harmless -- GNU Make ends the list at the blank line -- but misleading).
- debug_uart.c: uart_write() spun on a full ring buffer with nothing to drain it
(only uart_sync() advances tx_consume), so a burst larger than the buffer
deadlocked. Drain the FIFO while waiting, like uart_sync() does.
- wch-riscv.cfg: move the OpenOCD work area from 0x80000000 (unmapped) to the
0x20000000 SRAM, sized to 32 KB, matching ch32v20x/wch-riscv.cfg.
- family.c: implement board_get_unique_id() from the factory MAC. CH58x is a BLE
part, so a unique 6-byte MAC lives in FlashROM at ROM_CFG_MAC_ADDR; GetMACAddress()
reads it via FLASH_EEPROM_CMD (in libISP583.a), so no extra source file is needed.
The read buffer is TU_ATTR_ALIGNED(4) and 8 bytes, per the SDK's documented
4-byte-aligned, word-granular buffer contract (CH58x_flash.c).
- test/hil/tinyusb.json: key ch582m_evt off this board's actual MAC (D443627B5450)
instead of the fixed placeholder, like every other board.
Verified on ci.lan HIL: ch582m_evt enumerates with serial D443627B5450 and all
device examples pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
family.mk listed -nostartfiles and the nano/nosys specs under LDFLAGS_GCC, a variable
the make build system never reads (only LDFLAGS / LDFLAGS_CLANG are consumed by
gcc_rules.mk). So the make build linked the toolchain's crt0.o alongside the SDK's
startup_CH583.S and failed with "multiple definition of _start" + an undefined
__bss_start, and also pulled in full newlib (RAM blew up). Rename it to LDFLAGS,
matching ch32v20x/family.mk. The cmake build was unaffected (it sets these via
target_link_options). Fixes the CircleCI one-random-make-ch58x build.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The dependency is fetched from https://github.com/openwch/ch583.git but lived at
hw/mcu/wch/ch58x. Rename the local path to hw/mcu/wch/ch583 so it matches the
upstream repo name. Updates the get_deps.py path key and the ch58x BSP SDK_DIR
(family.mk + family.cmake); the BSP family stays "ch58x" (covers CH582 and CH583).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The classic-USB STM32 fsdev driver enabled the EXTI-line USB wakeup interrupt
(USBWakeUp_IRQn, and USBWakeUp_RMP_IRQn on the F3 remap path) in the NVIC, but
never uses it: resume is serviced in-band via ISTR.WKUP in the USB_LP/HP ISR,
and the driver never arms or clears that EXTI line. The wakeup EXTI interrupt is
only needed to wake the core from STOP mode, which TinyUSB does not implement.
Leaving its NVIC vector enabled lets it fire spuriously into an unhandled or
looping vector -- the freeze reported in #3696 on STM32G473.
USBWakeUp_IRQn is a valid, dedicated USB-wakeup-via-EXTI interrupt (e.g.
stm32g473xx.h: =42 "USB Wakeup through EXTI line"), not an "unrelated
interrupt"; it is simply unused here.
- Comment out USBWakeUp_IRQn for F1/F3/G4/L1 and USBWakeUp_RMP_IRQn on the F3
remap path, kept in place so STOP-mode wakeup is a one-line re-enable.
- Keep the STM32L1 USBWakeUp_IRQn -> USB_FS_WKUP_IRQn alias for that re-enable.
- Document the rationale in fsdev_stm32.h with a TODO.
- Comment out the matching USBWakeUp(_RMP)_IRQHandler in the F1/F3/G4 BSPs, and
the FreeRTOS NVIC_SetPriority(USBWakeUp_IRQn) on F1/G4.
Fixes#3696
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Replace PR #3515's separate dcd_ch58x_usbfs.c / hcd_ch58x_usbfs.c with the
shared WCH USBFS device driver (combined per-endpoint control, like CH32V103),
adding two CH58x-specific behaviors guarded so CH32V103/V20x/V307 are unchanged:
- CH32_USBFS_EP_MANUAL_TOG: CH58x's hardware AUTO_TOG does not stay in sync, so
the ISR toggles DATA0/DATA1 manually and discards toggle-mismatched OUT
packets. Fixes multi-packet bulk-IN (e.g. MSC READ10) that otherwise hung.
- CH32_USBFS_EP4_SHARES_EP0: EP4 has no DMA register and overlays EP0's region
(EP0[0:63] + EP4 OUT[64:127] + EP4 IN[128:191]); add a 192-byte shared buffer
and buffer-pointer helpers (transparent for the other parts). Fixes
cdc_dual_ports (Port1 is on EP4).
Add the ch582m_evt board. Device only on USB0 (rhport 0): the shared
hcd_ch32_usbfs.c is CH32V20x-specific and cannot drive CH58x, so host / USB2
(rhport 1) is left commented out in the BSP for easy re-add.
Verified on ch582m_evt via local HIL: all device examples pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
CH32V103 uses the older USBFS IP: a single combined UEPn_CTRL register per
endpoint (IN response in bits [1:0], OUT response in [3:2], shared auto-toggle,
separate IN/OUT toggles) instead of the separate UEPn_TX_CTRL/UEPn_RX_CTRL
bytes of the newer IP (CH32V20x/V307). The shared driver was written for the
newer IP, so EP0 control transfers never worked on V103: the OUT response was
written to a reserved byte and the IN write clobbered the OUT bits.
- ch32_usbfs_reg.h: annotate the V103 register struct with byte offsets and add
a union exposing the combined UEPn_CTRL at the UEPn_TX_CTRL offset; define
CH32_USBFS_EP_CTRL_COMBINED and the combined-register bit positions.
- dcd_ch32_usbfs.c: abstract EP control access behind ep_tx/rx_ctrl_set() (full
write) and ep_tx/rx_set_response() (response-only RMW). The newer-IP path is
unchanged; the combined path read-modify-writes the single register and arms
the post-SETUP data stage at DATA1.
- bsp/ch32v10x: implement board_get_unique_id() (real chip UID) and drop the
CSR 0x800 writes that corrupted the QingKe V3 interrupt config and left all
interrupts disabled (the USB ISR never ran).
Verified on ch32v103r_r1_1v0: enumerates and passes HIL for cdc_msc, hid,
msc, midi, mtp, dfu, etc.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Fix stm32f723disco host HIL: UART RX starvation + DWC2 split bulk NAK/XactErr handling (#3677)
stm32f7 BSP — UART RX starvation
- The host console USART shared interrupt priority with the USB OTG ISR, so a long
OTG interrupt could starve RXNE and drop received bytes. Raise the USART RX IRQ
above OTG_FS/OTG_HS in both the bare-metal and FreeRTOS init paths, guarded by
#ifdef UART_ID so boards without a UART console keep the default OTG priority.
dwc2 host — split NAK/XactErr handling
- Slave mode: a persistently-NAKing split bulk/control IN poll re-armed the
start-split immediately, storming the ISR and starving task context. Throttle by
disabling the channel and re-arming on the resulting halt (no frame deferral).
- Buffer-DMA mode: a pure split bulk-OUT NAK was unhandled, leaving the channel
halted and stalling the transfer — the dominant cause of CDC echo truncation.
Handle it by rewinding the buffer pointers and retrying the start-split
(Programming Guide v4.20a 5.1.4.2).
- Buffer-DMA mode: a split bulk-OUT XactErr was retried immediately, exhausting
HCD_XFER_ERROR_MAX before the transient cleared. Throttle via channel_disable +
re-arm to give the hub TT a recovery gap, mirroring slave mode.
- All three are scoped to split transfers (hcsplt.split_en); non-split NAK/XactErr
keep the core-handled / immediate-retry behavior. The OUT XactErr throttle also
excludes periodic split, where channel_disable() is a no-op and would wedge the
channel. The nak_disabled flag is generalized to retry_disabled and honors
xfer->closing so an endpoint close during a throttled retry tears down cleanly.
Verified on stm32f723disco HIL (slave + CFG_TUH_DWC2_DMA_ENABLE): host/cdc_msc_hid,
msc_file_explorer, and device_info all pass on both variants; DMA CDC echo went
from ~15-25% raw failure to 10/10 clean.
Per review (HiFiPhile): Ninja Multi-Config is needed for IAR, otherwise the
optimization level can't be lowered to none for debug. Revert gen_presets.py
back to Ninja Multi-Config (keeping only the cmake-build-<board> binaryDir
change), and instead teach hil_test.py to locate <ex>.elf whether it sits
directly in the example dir (single-config) or under a per-config subdir like
RelWithDebInfo/ (multi-config).
Verified: stm32u083nucleo passes 13/13 remote HIL with a multi-config preset
build (rsync preserves the RelWithDebInfo/ subdir; the resolver finds it).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Change the default configure preset binaryDir from build/<board> to
cmake-build-<board> (the dir name HIL expects) and switch the generator
from Ninja Multi-Config to single-config Ninja. Multi-Config nests
binaries under a RelWithDebInfo/ subdir, which hil_test.py does not look
in; single-config emits device/<ex>/<ex>.elf so preset-built firmware is
directly consumable by `hil_test.py -B examples`.
Regenerated BoardPresets.json (also picks up the tracked ch32v103c_bluepill
board that was missing from presets).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Previously stm32u0 had no board_get_unique_id(), so it fell back to the
weak default in hw/bsp/board.c and every board reported the placeholder
USB serial 0123456789ABCDEF. HIL identifies boards by USB serial, so a
non-unique serial collides on a multi-board rig. Read the 96-bit unique
ID from UID_BASE, mirroring stm32u5. Verified on stm32u083nucleo: now
enumerates as 300044000D5036394E373620.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
