<feed xmlns='http://www.w3.org/2005/Atom'>
<title>tinyusb.git/src/portable/st/stm32_fsdev, branch worktree-ch569-hydrausb3</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/tinyusb.git/atom/src/portable/st/stm32_fsdev?h=worktree-ch569-hydrausb3</id>
<link rel='self' href='http://cgit.235523.xyz/tinyusb.git/atom/src/portable/st/stm32_fsdev?h=worktree-ch569-hydrausb3'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/tinyusb.git/'/>
<updated>2026-07-06T09:17:17Z</updated>
<entry>
<title>Merge remote-tracking branch 'origin/master' into usbtest</title>
<updated>2026-07-06T09:17:17Z</updated>
<author>
<name>hathach</name>
<email>thach@tinyusb.org</email>
</author>
<published>2026-07-06T09:17:17Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/tinyusb.git/commit/?id=2d73cf58de9a41278a9c6e1e3c9e5c6626bf95b7'/>
<id>urn:sha1:2d73cf58de9a41278a9c6e1e3c9e5c6626bf95b7</id>
<content type='text'>
# Conflicts:
#	lib/rt-thread/port/msc_device_port.c
#	src/device/usbd.c
</content>
</entry>
<entry>
<title>dcd(fsdev): don't disarm an armed endpoint on clear-halt toggle reset</title>
<updated>2026-07-03T07:13:29Z</updated>
<author>
<name>hathach</name>
<email>thach@tinyusb.org</email>
</author>
<published>2026-07-03T07:13:29Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/tinyusb.git/commit/?id=9ef85788b7e888c0eb8152c9b7419b4326e1c905'/>
<id>urn:sha1:9ef85788b7e888c0eb8152c9b7419b4326e1c905</id>
<content type='text'>
usbtest case 29 clears the endpoint halt on a NON-stalled bulk endpoint to
reset the data toggle, then keeps streaming. fsdev's dcd_edpt_clear_stall
unconditionally forced STAT to NAK, which disarms a VALID (armed) endpoint
with no completion event -&gt; the usbd claim leaks and the sink never re-arms,
so the toggle desyncs (EINVAL).

fsdev's data toggle (DTOG) is a hardware bit independent of the arm state, so
the toggle can be reset without disarming. Only knock a genuinely STALLED
endpoint down to NAK (the class then re-arms); for an armed/idle endpoint,
mask the STAT bits to 0 (no toggle-write) so it keeps its current status while
DTOG is still reset to DATA0. The stall-recovery path (test 13) is unchanged.

Full usbtest battery now 30/30 (was 29/30) on stm32f072disco (F0, 16-bit
fsdev), stm32g0b1nucleo (G0, 32-bit fsdev) and stm32u083nucleo (U0); test 13
(ep halt) still passes on all three. Shared file also builds for the ch32
fsdev variant (no such board on the rig to run).

Co-Authored-By: Claude Fable 5 &lt;noreply@anthropic.com&gt;
Claude-Session: https://claude.ai/code/session_01HeF2gZ1M7GWkz6Av4BpKPg
</content>
</entry>
<entry>
<title>license: use SPDX identifiers for src/ headers (#3749)</title>
<updated>2026-07-02T14:55:45Z</updated>
<author>
<name>Ha Thach</name>
<email>thach@tinyusb.org</email>
</author>
<published>2026-07-02T14:55:45Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/tinyusb.git/commit/?id=7a4111b96ef6279e75579f9a18443834f6a0871d'/>
<id>urn:sha1:7a4111b96ef6279e75579f9a18443834f6a0871d</id>
<content type='text'>
* license: use SPDX identifiers for src/ headers

Replace the full ~20-line MIT license boilerplate on every src/ file with a
two-line SPDX tag (SPDX-FileCopyrightText + SPDX-License-Identifier), following
the REUSE convention used by CircuitPython and the Linux kernel. Removes ~3500
lines of duplicated boilerplate.</content>
</entry>
<entry>
<title>Merge pull request #3648 from hathach/ch32_fsdev</title>
<updated>2026-06-24T06:27:18Z</updated>
<author>
<name>Ha Thach</name>
<email>thach@tinyusb.org</email>
</author>
<published>2026-06-24T06:27:18Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/tinyusb.git/commit/?id=467f638e98d5b76ecb970272912a1b1f63a7ca19'/>
<id>urn:sha1:467f638e98d5b76ecb970272912a1b1f63a7ca19</id>
<content type='text'>
dcd/stm32_fsdev: workaround CH32 EP0 premature OUT ACK</content>
</entry>
<entry>
<title>fix(stm32_fsdev): don't enable the unused USB wakeup EXTI IRQ (F1/F3/G4/L1)</title>
<updated>2026-06-18T11:09:53Z</updated>
<author>
<name>hathach</name>
<email>thach@tinyusb.org</email>
</author>
<published>2026-06-18T10:44:16Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/tinyusb.git/commit/?id=d0e51346cdc691624bc10da89a775a82ef86d92a'/>
<id>urn:sha1:d0e51346cdc691624bc10da89a775a82ef86d92a</id>
<content type='text'>
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 -&gt; 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) &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>dcd/stm32_fsdev: restore CH32 EP0 CONTROL type when stalling</title>
<updated>2026-06-18T08:56:23Z</updated>
<author>
<name>hathach</name>
<email>thach@tinyusb.org</email>
</author>
<published>2026-06-17T09:27:03Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/tinyusb.git/commit/?id=6d74543ce6b3d79c2ba24e11f23fccad52571464'/>
<id>urn:sha1:6d74543ce6b3d79c2ba24e11f23fccad52571464</id>
<content type='text'>
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 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>dcd/stm32_fsdev: restore CH32 EP0 CONTROL type atomically with arming</title>
<updated>2026-06-18T08:56:23Z</updated>
<author>
<name>hathach</name>
<email>thach@tinyusb.org</email>
</author>
<published>2026-06-17T09:26:38Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/tinyusb.git/commit/?id=de341b14abe3bc3e25962cbb26aa61bc0126adcf'/>
<id>urn:sha1:de341b14abe3bc3e25962cbb26aa61bc0126adcf</id>
<content type='text'>
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 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>dcd/stm32_fsdev: tidy CH32 EP0 setup parsing and whitespace</title>
<updated>2026-06-18T08:35:55Z</updated>
<author>
<name>hathach</name>
<email>thach@tinyusb.org</email>
</author>
<published>2026-06-18T08:35:55Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/tinyusb.git/commit/?id=47f534680215a68391a46cd45decde9b6f0a6573'/>
<id>urn:sha1:47f534680215a68391a46cd45decde9b6f0a6573</id>
<content type='text'>
Parse the setup packet via tusb_control_request_t instead of hand-rolled byte
indexing; drop a stray blank line and fix indentation. No functional change.

Co-Authored-By: Claude Fable 5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>dcd/stm32_fsdev: make CH32 ep0_set_type read-modify-write atomic</title>
<updated>2026-06-18T08:35:55Z</updated>
<author>
<name>hathach</name>
<email>thach@tinyusb.org</email>
</author>
<published>2026-06-17T09:23:19Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/tinyusb.git/commit/?id=8456821fc2bf54297932fd7e8381c3fe50359b0a'/>
<id>urn:sha1:8456821fc2bf54297932fd7e8381c3fe50359b0a</id>
<content type='text'>
ep0_set_type() read the EP0 register outside any critical section and
only ep_write() masked the USB IRQ around the store. A USB interrupt
landing between the read and the write (e.g. a new SETUP whose handler
installs the BULK gate) was silently undone when the task resumed and
wrote back its pre-interrupt snapshot with the type forced to CONTROL,
re-exposing the unsolicited EP0 OUT ACK the workaround blocks.

Bracket the whole read-modify-write with fsdev_int_disable/enable when
called with need_exclusive (task context). ISR-context callers pass
false and are unaffected (the ISR cannot preempt itself).

Co-Authored-By: Claude Fable 5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'master' into ch32_fsdev</title>
<updated>2026-06-12T16:59:13Z</updated>
<author>
<name>Ha Thach</name>
<email>thach@tinyusb.org</email>
</author>
<published>2026-06-12T16:59:13Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/tinyusb.git/commit/?id=50115d171321600954095fad7ac0e635e51c4c23'/>
<id>urn:sha1:50115d171321600954095fad7ac0e635e51c4c23</id>
<content type='text'>
</content>
</entry>
</feed>
