Hi all,
I’m working with a FS device on Win 7 – the device uses the latest WinUSB drivers. I am seeing a difference in the way Windows is handling the Transaction Translators (TTs) on two hubs. When I use the FS device on one hub, I see CLEAR_TT_BUFFER requests from the host, but with the other hub, I see RESET_TT requests from the host. The other fields in the TT requests are the same, but one gets RESET and the other gets CLEAR. The odd part about this is the hubs are on similar Dell monitors. The vendor is the same for both, and the PIDs is only 0x0010 apart. Everything else – the configuration descriptor, the interfaces, the other dev descriptor fields, the set interface, the hub descriptors, the set and clear requests… they are literally identical.
I don’t understand what could produce this slight difference in behavior. Since the only difference between the two hubs is the PID and bcdDevice, I can’t help but suspect Windows has some internal blacklist for certain hubs that causes this behavior.
It may seem weird that I’m interested in this issue, but the FS device I’m using allows me to open two file descriptors simultaneously, so I can access the device using two processes. Unfortunately, if I AbortPipe in WinUSB, the host sends these RESET_TT or CLEAR_TT_BUFFER requests, and since RESET_TTs aren’t ep/dev targeted (they only contain a target port number), the whole port gets temporarily killed. Most hubs I’ve seen get the CLEAR_TT requests, which are fine, because they target the particular EP pipe I’m aborting.
Any ideas? Thanks in advance!
Don