Unnamed repository; edit this file 'description' to name the repository. http://cgit.235523.xyz/tinyusb.git/atom/src?h=hil-report 2026-08-21T04:06:14Z 2026-08-21T04:06:14Z hathach thach@tinyusb.org 2026-08-21T04:06:14Z urn:sha1:a57f857f811e054e7a240fc55520648192349c2b vendor_host.c/.h implemented a CFG_TUH_VENDOR class driver that no example, board or test ever enabled: usbh's driver table entry was compiled out everywhere, and the six tusb_config.h files that mentioned the macro all set it to 0. Maintainer call - dead code, not a shrinking of supported classes. Removes the sources, the usbh driver-table entry, the CFG_TUH_VENDOR default in tusb_option.h, the tusb.h include, both build-system source lists, the rp2040 family.cmake entry and the IAR project template rows. 2026-08-19T11:33:12Z Ha Thach thach@tinyusb.org 2026-08-19T11:33:12Z urn:sha1:7800876bf151a239046521232dc4603b156061be dcd(ci_hs): stage the device address before priming the status stage 2026-08-19T10:40:48Z hathach thach@tinyusb.org 2026-08-19T05:29:45Z urn:sha1:75a01f561438c16677b48f3a59fda80a2b096ad8 IMXRT1060RM 42.7.23 and UM10503 Table 478 both ask for the DEVICEADDR write with USBADRA=1 to happen after the SET_ADDRESS data phase and before the prime of the status stage, so the controller loads USBADR from its holding register when the status stage is ACKed. The driver did it the other way round, leaving a window between the ENDPTPRIME store and the DEVICEADDR store: an IN answered inside that window ACKs with USBADRA still 0, so the holding register is never consulted and the device keeps answering on address 0 while the host has moved to the new one. Instruction timing alone cannot open that window, but dcd_set_address() runs in task context, so any interrupt landing between the two stores stretches it past a microframe. Hardware discards a staged address on a SETUP or OUT to endpoint 0 and zeroes USBADR on a bus reset, which covers a superseded SET_ADDRESS. What it cannot cover is a SETUP latched before this write and still unconsumed after the full CI_HS_BUSY_SPIN spin, which refuses the prime: condition 2 already fired for that earlier SETUP, so the stage would survive and load USBADR on the next EP0 IN ACK of an unrelated transfer. USB 2.0 9.4.6 is explicit that "the USB device does not change its device address until after the Status stage of this request is completed successfully", so the refused-prime path restores the previous USBADR rather than leaving a stage armed. Restoring the previous value rather than writing zero keeps 9.4.6's Address-state row correct, where a device already at a non-zero address must stay there; on Linux that write is always a no-op, since hub_set_address only issues SET_ADDRESS from USB_STATE_DEFAULT. Cast dev_addr before the shift: it is uint8_t, promoted to int, so an address of 64 or more reached the sign bit of a 32-bit int. No errata applies: IMXRT1060CE_A Rev 1.3 lists only ERR050101 and ERR010661 for USB, IMXRT1060CE_B Rev 1.1 only ERR010661. Validated on mimxrt1064_evk: 18/19 device+host tests, 6x usbtest 30/30, and a 100-iteration forced re-enumeration A/B that is clean on both this change and its parent (0/100 each). All 19 ci_hs boards build; unit tests 63/63; PVS drops one diagnostic (the sign-bit shift) and adds none. 2026-08-19T09:30:29Z Zixun LI admin@hifiphile.com 2026-08-19T09:30:29Z urn:sha1:82a577bde640c95ed25185af91c53b9f9f4ae29a ohci: fix double allocation of dummy TDs in gtd_find_free 2026-08-19T03:06:04Z HiFiPHile admin@hifiphile.com 2026-08-19T03:06:04Z urn:sha1:f065f280284a6f1b5b4c4d2849db4bff4a3ce70c 2026-08-19T03:00:20Z Zixun LI admin@hifiphile.com 2026-08-19T03:00:20Z urn:sha1:9c202e8c657e001c8d16753aa90046a5f373575f UAC2: Add more terminal types 2026-08-19T02:57:27Z HiFiPHile admin@hifiphile.com 2026-08-19T02:57:27Z urn:sha1:8c3b880735f11c37828d6c8b700170e6b6e405ce 2026-08-18T15:07:49Z hathach thach@tinyusb.org 2026-08-16T18:02:54Z urn:sha1:19ff2ed615e4a97984aab5551ac8835ead53b9e7 ERR050101: while an isochronous IN endpoint is active, an IN token addressed to that same endpoint number on ANOTHER device sharing the host can silently unprime one of this device's OUT endpoints - control, bulk, interrupt or isochronous alike. NXP states it cannot be detected by software and raises no interrupt, so the endpoint simply stops answering and the transfer never completes. The workaround is a uniqueness requirement rather than a particular number: the isochronous IN endpoint must not share its number with any IN endpoint in use on the bus. One family-wide constant therefore defeats it, since two affected boards on the same hub then pick the same number and each becomes the other's aggressor. CFG_TUSB_MIMXRT1XXX_ERRATA_ERR050101 is set only for the parts whose errata list it - RT1015, RT1020, RT1024 and RT1050, where it is marked no fix scheduled, plus RT1060 and RT1064 rev A - so RT1010 and the RT11xx family keep the ordinary number and cannot collide with an affected board beside them. Several affected boards on one hub can still be given distinct numbers with -DEPNUM_ISO_IN. The guard covers every example that has an isochronous IN endpoint: audio_test, audio_4_channel_mic, uac2_headset, cdc_uac2, usbtest, video_capture and video_capture_2ch. The video examples move the endpoint only when streaming isochronously, since the bulk configuration is unaffected, and video_capture_2ch takes two numbers because it has two streams. The macro name follows CFG_TUSB_RP2_ERRATA_E2/E4/E15 already in tree, and its is fixed, and which cannot be told apart at compile time - a way to define it to 0. device_issues.rst records ERR050101 against every affected part with a link to each errata sheet, and adds the LPC55S2x USB.3 speed-detection and USB.5 isochronous IN entries, neither of which TinyUSB works around. The branch's design notes are included under docs/superpowers. Verified: 340 wedge-free runs on mimxrt1064_evk, which previously wedged within hours, and the macro resolving to endpoint 0x87 on mimxrt1064_evk against 0x83 on mimxrt1010_evk and stm32f407disco. 2026-08-18T15:07:49Z hathach thach@tinyusb.org 2026-08-16T18:02:22Z urn:sha1:5baf5925c8b6a033de85e3b5537ea879de75e3da DEVCMDSTAT mixes read/write fields with write-1-to-clear latches, so a blind read-modify-write writes a pending latch back as a one and silently clears it - a setup consumed that way strands EP0. Mask the latches on every update. The setup path follows the manual's order: acknowledge the latch, then read the payload. The EP0 IN interrupt is cleared along with EP0 OUT, as the control endpoint flowchart requires - a control IN completion latched before the setup must not reach usbd after it, where it would be applied to the request the setup just started and arm its status stage early. The payload is copied a byte at a time out of a buffer now declared volatile: the controller DMAs a new setup packet into it as soon as the latch is cleared, and C orders volatile accesses only against each other, so gcc sinks a plain memcpy below the guard read that follows at -O2 and -O3 - leaving only -Os, the level CI builds, correct. 2026-08-18T15:07:49Z hathach thach@tinyusb.org 2026-08-16T18:02:07Z urn:sha1:a85a6afc6d98726f5edfb2d7606527c87c963dba A refused transfer is a recoverable condition - a new setup superseding a control response, for instance - rather than a bug, but every failure path treated it as one. TU_ASSERT carries TU_BREAKPOINT, which is gated on a debugger being attached rather than on CFG_TUSB_DEBUG, so on a rig where a probe is always attached it halted the CPU even in release builds. Use TU_VERIFY on the control transfer paths, including the multi-packet data stage continuation, and drop the breakpoint from the endpoint transfer failure arm, which already marks the endpoint ready again so the next transfer can proceed. The result of usbd_control_xfer_cb() was separately dropped on the floor, leaving EP0 neither armed nor stalled and nothing recorded. It is logged now, and deliberately not stalled: a DCD refuses an EP0 prime when a newer setup is already latched, and EP0 stalls are cleared by hardware when that setup arrives, so a stall issued here would land after the auto-clear and stall the transfer that superseded this one. The pending setup re-drives EP0 by itself.