You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Often a write from the host to the control channel, i.e. a type 0 packet immediately followed by a type 1 packet of arbitrary length, often fails in USB 2 mode. This appears to be related to getting "just the right timing". It causes FreeBSD (and possibly windows) to fail to recognize a CAM device class, as during a part of the initialization, a packet is sent to the control channel to initialize the class parameters.
This may be due to the incorrect setting of flags in the control endpoint's control register, such that a 'nack' is not generated when the endpoint is unable to receive a type 1 packet following receipt of the type 0 packet.
It seems that these things happen very fast, and the ISR may simply not be fast enough to keep up. The correct 'flag magic' needs to be done so that the first type 1 packet write attempt gets the 'nack', forcing a retry. If the host is NOT retrying it may be possible to physically wait for the type 1 packet to arrive within the ISR itself, which isn't desirable [but there may be no other choice].
The text was updated successfully, but these errors were encountered:
bombasticbob
changed the title
USB write to control channel often fails
USB host write to control channel often fails
May 18, 2018
Often a write from the host to the control channel, i.e. a type 0 packet immediately followed by a type 1 packet of arbitrary length, often fails in USB 2 mode. This appears to be related to getting "just the right timing". It causes FreeBSD (and possibly windows) to fail to recognize a CAM device class, as during a part of the initialization, a packet is sent to the control channel to initialize the class parameters.
This may be due to the incorrect setting of flags in the control endpoint's control register, such that a 'nack' is not generated when the endpoint is unable to receive a type 1 packet following receipt of the type 0 packet.
It seems that these things happen very fast, and the ISR may simply not be fast enough to keep up. The correct 'flag magic' needs to be done so that the first type 1 packet write attempt gets the 'nack', forcing a retry. If the host is NOT retrying it may be possible to physically wait for the type 1 packet to arrive within the ISR itself, which isn't desirable [but there may be no other choice].
The text was updated successfully, but these errors were encountered: