Prev: Application compiled with Win2K/XP DDK works fine. But doesnt work with WIN98 DDK
Next: Virtual COM port emulation over USB
From: Steve Whitman on 7 Oct 2005 09:52
We are using a TI TUSB3410 USB to Serial chip and recently identified an
issue when using this device with a Philips based ISP1521 based Hub. On the
USB-IF Developers Discussion Forum a post was made that matches our problem
exactly. This post also has a statement that Philips apparently made which
states the issue is that the Windows USB host controller driver. Basically
Philips states that the host controller driver is not terminating Start Split
transactions with a Complete Split transaction. For the original posting see
http://www.usb.org/phpbb/viewtopic.php?t=6636&highlight=tusb3410&sid=92ad332153ccee7ed3babd646910e98d.

We have been told by TI that Microsoft acknowledges that this is a bug and
that it will be fixed in Vista. However in the meantime our customers are
experiencing problems when using our hardware with ISP1521 based hubs. My
question is, how can we work around this issue? Is there something we can do
in our application or in the driver to cause the host controller driver to
terminate the split transaction?

Thanks in advance for any help in resolving this issue.
- Steve -

From: "Martin Borve [MSFT]" on 10 Oct 2005 18:22
There is no workaround for this problem in XP/Server 2003. The problem
occurs when a client USB driver cancels a IN transfer that is currently
waiting for a complete split. Canceling the transfer causes the queue head
for the endpoint to be removed from the schedule, which means the host
controller will not know to send the complete split for the transfer.

This is normally not an issue, as the next time a transfer is scheduled for
that endpoint, the hub will ignore the start split, and then process the
following complete split as normal. The problem occurs when you have 2 of
the devices both cancel pending IN transfers, leaving both TT buffers busy.
As the Phillips hub has 2 TT buffers, it will prevent other transfers from
occurring until another transfer is scheduled for one of the IN endpoints.
The TI driver needs to to a control transfer before doing so, so transfers
simply halt at this point.

Vista will resolve this problem by always issuing a clear TT buffer command
whenever a transaction is cancelled for one of these endpoints.

Martin Borve
Windows DDK Support
This posting is provided "AS IS" with no warranties, and confers no rights.


From: Steve Whitman on 11 Oct 2005 08:26
Hello Martin,

Thanks for the information. I already suspected that there wasn't a
workaround to this problem.
Am I correct in assuming that this problem will not occur with the root hub?
I'm asking because it is normal for our customers to power cycle our devices
so we can direct them to purchase hubs that are self powered and not bus
powered. That way they can power cycle the hub at the same time they power
cycle our devices.

- Steve -


From: "Martin Borve [MSFT]" on 11 Oct 2005 18:53
Correct. This is only a potenial problem with external USB 2.0 hubs.

Martin Borve
Windows DDK Support
This posting is provided "AS IS" with no warranties, and confers no rights.


 | 
Pages: 1
Prev: Application compiled with Win2K/XP DDK works fine. But doesnt work with WIN98 DDK
Next: Virtual COM port emulation over USB