tinyusb.git/src/portable/nordic, branch worktree-ch569-hydrausb3

address review round 2 (4 fixed, 1 answered)

2026-07-06T18:23:38Z

- dcd(nrf5x): dcd_edpt_iso_activate drops a stale armed transfer (started/ data_received/iso_in_transfer_ready) — there is no dcd close on this port, so a transfer armed before SET_INTERFACE would trip TU_ASSERT(!xfer->started) on the class's next arm after usbd reset the endpoint's claim state. - class(vendor): tud_vendor_n_mounted() counts the interrupt endpoints, so an interrupt-only vendor interface (bulk absent) reports mounted. - example(usbtest): int/iso write lengths follow the negotiated speed (tud_speed_get), not the compile-time capability — a high-speed build enumerated at full speed serves the FS descriptor (mps 64/128) and must not submit HS-sized packets. - test/hil: test_example() return annotation matches the (err, status, metric) 3-tuple it returns. Verified: feather_nrf52840_express and raspberry_pi_pico 30/30 through the HIL battery; pico/feather/ch32v307-usbhs builds clean. Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01HeF2gZ1M7GWkz6Av4BpKPg

Merge remote-tracking branch 'origin/master' into usbtest

2026-07-06T09:17:17Z

# Conflicts: # lib/rt-thread/port/msc_device_port.c # src/device/usbd.c

dcd(nrf5x): implement Errata 199 workaround (USBD drops tokens during DMA)

2026-07-04T01:50:34Z

The nRF52840 has anomaly 199 "USBD cannot receive tasks during DMA": while an EasyDMA transfer is in progress the controller can drop an incoming SETUP/IN/OUT token, producing a lost event that stalls EP0. Under rapid back-to-back control transfers this hangs the device -- reproducible with the Linux usbtest "queued control" case (test 10), which wedged testusb into an unrecoverable D-state. TinyUSB included nrf_erratas.h but implemented none of the workaround. Latch the undocumented "DMA in progress" test register (0x40027C1C = 0x82) around each real EasyDMA in start_dma() and clear it (0x00) in edpt_dma_end(), gated on nrf52_errata_199() so unaffected nRF52 parts skip it. Mirrors nrfx's usbd_dma_pending_set()/usbd_dma_pending_clear(). Verified on feather_nrf52840_express: usbtest test 10 now passes across 12 isolated runs (was a hard hang) and the full tier-4 battery is 30/30. Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_01HeF2gZ1M7GWkz6Av4BpKPg

dcd: retire dcd_edpt_close() on the iso-migrated drivers

2026-07-03T10:46:21Z

Now that ip3511, rusb2 and nrf5x are on ISO_ALLOC, the stack's usbd_edpt_close() is a no-op for them, so dcd_edpt_close() is no longer a public DCD entry point. Audit of the remaining callers: - ip3511, nrf5x: dcd_edpt_close_all() does its own teardown and no longer calls dcd_edpt_close() -> it is dead code, removed. - rusb2: dcd_edpt_close_all() still tears down each pipe via it -> kept but made a static internal helper (edpt_close), not a public dcd_ API. Revert dcd.h to declaring dcd_edpt_close() only under TUP_DCD_EDPT_CLOSE_API (for the remaining close-API MCUs); ISO_ALLOC IPs declare iso alloc/activate instead. Behaviour-neutral (removed/renamed uncalled functions); dwc2 still builds and nrf5x still passes bulk/iso/halt on hardware. Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01HeF2gZ1M7GWkz6Av4BpKPg

dcd: implement iso alloc/activate for rusb2, ip3511, nrf5x; deprecate CLOSE_API for them

2026-07-03T10:14:20Z

Migrate the ip3511, rusb2 and nrf5x DCDs off the deprecated TUP_DCD_EDPT_CLOSE_API path onto the unified ISO_ALLOC model by implementing dcd_edpt_iso_alloc/activate (previously #if0 stubs / returning false): - rusb2: iso_alloc reserves an ISO-capable pipe (1/2) once and configures it; iso_activate re-arms it in place (PIPEMAXP + SQCLR + PID_BUF) with no pipe free/realloc, avoiding PIPESEL/PIPECFG churn across altsetting changes. - ip3511: iso_alloc reserves the EP command/status entry (type=ISO, INTEN); iso_activate clears stall + resets the data toggle. - nrf5x: iso_alloc validates the fixed EP8; iso_activate enables ISOOUT/ISOIN (with ISOSPLIT when both directions are active) + SOF, mirroring dcd_edpt_open. tusb_mcu.h no longer defines CLOSE_API for these three (they fall through to ISO_ALLOC); dcd_edpt_close is now declared unconditionally in dcd.h since these drivers still use it internally from dcd_edpt_close_all(). The remaining CLOSE_API MCUs (mm32, pic, da1469x, f1c100s, ch32-usbhs) are left for a later per-board pass. Verified on hardware: ip3511 (lpcxpresso11u37) 29/30 and nrf5x (feather_nrf52840) iso 11/11 via the new path (identical to their prior CLOSE_API results); dwc2, fsdev, rp2040 + audio/video still build. rusb2 (ra4m1) has a separate, iso-independent set_interface wedge (still 1/30) tracked for follow-up. Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01HeF2gZ1M7GWkz6Av4BpKPg

license: use SPDX identifiers for src/ headers (#3749)

2026-07-02T14:55:45Z

* 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.

nrf5x: request HFCLK in USB_EVT_READY to fix post-SoftDevice deadlock

2026-05-08T14:27:53Z

USB_EVT_DETECTED runs hfclk_enable() which, when SoftDevice is not yet enabled, starts HFXO via direct CLOCK register access. After sd_softdevice_enable() takes over CLOCK, HFXO is physically off again and SD's HFCLK reference count is 0. If USB_EVT_READY is fired post-SD (e.g. on nRF52 via Bluefruit's usb_softdevice_post_enable() when the pre-SD nrfx_power READY callback didn't get to run before nrfx_power was uninited), the wait loop 'while (!hfclk_running()) {}' calls sd_clock_hfclk_is_running() which returns false forever -> deadlock that blocks both USB enumeration and any further app code on the calling thread. Call hfclk_enable() right before the wait so HFCLK is requested in whichever context (SD or direct) is current. hfclk_enable() is idempotent. Reproduces reliably with bleuart on Feather nRF52840 Express flashed via JLink: chip wedges in sd_clock_hfclk_is_running SVC, no USB enumeration, no BLE advertising. With the fix, USB enumerates and BLE advertises as expected.

fix some Wconversion warnings

2026-04-17T03:16:31Z

fix build with zephyr with latest nrfx v4

2025-11-28T06:34:00Z

Merge remote-tracking branch 'tinyusb/master' into copilot/fix-dcd-edpt-xfer-issue

2025-11-19T21:05:07Z

Signed-off-by: HiFiPhile