tinyusb.git/src/portable/st, branch 0.21.0

Merge pull request #3616 from michaelajax/fix-stm32-usbc

2026-06-25T08:24:39Z

typec/stm32: fix UCPD sink bugs affecting compatibility with newer PD sources

skip cable-plug traffic

2026-06-24T21:41:43Z

Signed-off-by: HiFiPhile

apply review suggestions

2026-06-24T19:36:03Z

Signed-off-by: HiFiPhile

typec: add tuc_connect/tuc_disconnect api

2026-06-24T19:15:33Z

Signed-off-by: HiFiPhile

typec: add stm32u5 support

2026-06-24T19:13:27Z

Signed-off-by: HiFiPhile

Merge pull request #3648 from hathach/ch32_fsdev

2026-06-24T06:27:18Z

dcd/stm32_fsdev: workaround CH32 EP0 premature OUT ACK

Merge remote-tracking branch 'tinyusb/master' into fix-stm32-usbc

2026-06-23T21:12:51Z

fix(stm32_fsdev): don't enable the unused USB wakeup EXTI IRQ (F1/F3/G4/L1)

2026-06-18T11:09:53Z

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)

dcd/stm32_fsdev: restore CH32 EP0 CONTROL type when stalling

2026-06-18T08:56:23Z

The CH32 workaround only restored EP0 to CONTROL in edpt_xfer(). When the stack rejects a control write with data (handle_ctr_setup having already switched EP0 to BULK) it stalls EP0 via dcd_edpt_stall() without ever calling dcd_edpt_xfer(), leaving EP0 typed BULK+STALL. As SETUP recognition is tied to CONTROL-typed endpoints, the host's recovery SETUP (which should auto-clear the stall) would be ignored, wedging EP0 until a bus reset. Restore CONTROL for EP0 in the same exclusive write that sets the STALL status. DFU download-in-wrong-state is a concrete trigger. Co-Authored-By: Claude Fable 5

dcd/stm32_fsdev: restore CH32 EP0 CONTROL type atomically with arming

2026-06-18T08:56:23Z

edpt_xfer() restored EP0 to CONTROL at the top of the function, before the OUT stage was armed (rx bufsize + STAT_RX=VALID written further down, with interrupts enabled in between). That re-enabled the CH32 blind OUT ACK while STAT_RX was still NAK and the buffer size stale, so a host-retried DATA OUT / status ZLP could be ACKed into the wrong buffer in the gap. Fold the CONTROL restore into the single exclusive write that programs STAT_RX=VALID for the OUT direction, after the buffer size is set, so type and arming go live together. The IN direction keeps the (now atomic) early restore, where no pending OUT exists to be blind-ACKed. Co-Authored-By: Claude Fable 5