Unnamed repository; edit this file 'description' to name the repository. http://cgit.235523.xyz/tinyusb.git/atom/src/portable?h=update-sponsor 2026-08-19T11:33:12Z 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-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:01:54Z urn:sha1:2fda873fa5f6ef0c893f4f138b5c54e49c24e0a9 A bus reset was detected only from the port change that ends it, which is late: the manual asks the DCD to clear the endpoint semaphores, cancel every prime and free the dTDs while the reset is still being driven. Enable the reset interrupt and do all of that there, in the manual's order (IMXRT1060RM 42.5.6.2.1, p.2394), including the two steps that were missing - confirming the port is still being reset, and freeing the dTDs. A failed check means the cleanup arrived late and the controller may be in an undefined state, so the manual's remedy is carried out rather than noted: a controller reset, followed by the full re-initialisation it then requires, since the reset detaches the device. The port change that ends the reset is left with what the manual gives it, the negotiated speed, which the new BUS_RESET_END event carries. A port change is classified by the interrupt that preceded it: a suspend raises no port change of its own, the resume that ends it does. Every unbounded register spin is now bounded. They waited on bits the hardware clears within a frame, but each could hang an interrupt handler outright on a controller that had stopped responding. The endpoint flush follows all three steps of IMXRT1060RM 42.5.6.6.5 (p.2413), repeating a flush the controller refuses while a packet is in progress - previously reported as success. EP0 setup handling is hardened alongside: the payload is copied out of the queue head through the volatile qualifier before ENDPTSETUPSTAT is cleared, since that clear releases the setup lockout and a back-to-back setup can overwrite the buffer immediately after, and C orders volatile accesses only against each other, so a plain memcpy may legally be sunk past the store. There is deliberately no unplug detection. IMXRT1060RM 42.7.31 (p.2470) states a zero Current Connect Status means the device "did not attach successfully or was forcibly disconnected by the software writing a zero to the Run bit ... It does not state the device being disconnected or suspended", so a cable pull raises no port change at all; VBUS via OTGSC is the manual's disconnect indicator and is board dependent. Verified on mimxrt1064_evk: 30 forced bus resets each re-enumerating at high speed with no descriptor errors, plus repeated full usbtest batteries at 30/30 across the series. 2026-08-17T09:29:52Z Ryzee119 wendland@live.com.au 2026-08-12T12:19:00Z urn:sha1:18bb2d650404432d0c6c61c26e98c7074f46ec6b 2026-08-17T05:12:08Z hathach thach@tinyusb.org 2026-08-13T07:35:01Z urn:sha1:8ccd0d549798c66d484e5a4b4c57edf49e8bb097 Replace the duplicated per-MCU dispatch in dcd_init/hcd_init and the two helper flavors (USB_Type access on iMX RT, raw offset 0x90 on LPC18/43) with one SBUSCFG register field plus a per-header CI_HS_SET_AHB_BURST() hook, compiled only where defined. The LPC USB0-only policy is now visible at the macro definition. 2026-08-12T11:11:28Z Ryzee119 wendland@live.com.au 2026-08-12T11:10:15Z urn:sha1:73e787ae418df76b79ac0fd31bb0674a72e68c88 2026-07-29T19:35:02Z hathach thach@tinyusb.org 2026-07-29T19:35:02Z urn:sha1:6271842ea874812f1157b42bcd650c59ab59259b