diff options
| author | hathach <[email protected]> | 2026-08-17 01:01:54 +0700 |
|---|---|---|
| committer | hathach <[email protected]> | 2026-08-18 22:07:49 +0700 |
| commit | 2fda873fa5f6ef0c893f4f138b5c54e49c24e0a9 (patch) | |
| tree | 57dd6c3639ba3d046b7cdf9289a4eb1b50cc271c /docs/html_extra | |
| parent | 073942589355676980ba401cb88c0eb9f065e468 (diff) | |
dcd(ci_hs): rework bus reset handling and bound the register waits
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.
Diffstat (limited to 'docs/html_extra')
0 files changed, 0 insertions, 0 deletions
