EE here. I was tasked with building a USB Hub onto one of our boards, and I chose the TI part TUSB2077A. Everything seems to work properly except when I disconnet one of our devices, but it doesn't happen all the time; I can safely say that it happens about 5% of the disconnections.
My initial assumption was that it had to do with improper layout, ESD, surge or any other electrical problem you can think up. I got all my toys out and started measuring, scoping, cutting traces, adding components, removing components, but no matter how much I did, I would always be able to duplicate the problem with the same frequency of occurrence.
I decided to sniff around the USB traffic and see what I could find, but device drivers are completely out of my expertise and I am unable to interpret the logs. I have been googling around many of the things I see, and they differences in the two logs are more than obvious, but I am still unable to determine if this is a faulty device driver, a faulty Windows usbhub.sys driver, or an error within the TI chip itself. Out of all the possibilities, I believe the fault device driver is the more likely, but before I contact my device provider, I wanted to understand better what is going on.
Can any USB expert out there take a look at these logs and tell me what you can interpret from them? I captured the full USB stack, so there are a lot of Bulk transfer messages, but if you scroll down about 1.8 seconds in you will see the magic happen.
https://www.dropbox.com/s/epdhsf9lcox5ci7/Full%20Stack%20Logs.zipMORE DETAILS
The device in question is a custom made thermal ticket reader that uses the Thesycon usbio generic USB driver. I did not design this device, nor the device driver. It has been in use by our company for about 10 years, but this would be the first time it is connected to a USB Hub, before it was always connected to the Root Hub in a Host PC running Windows XP. I only designed the USB Hub, using the above mentioned TI Part.
The problem:
When unpluggin the device from the Hub, the hub will reset and re-enumerate itself and therefor the devices attached to it. I have checked the reset line in the hub and it is not asserted, nor is VCC dropped by any level that would cause an electrical malfunction.
I have also checked for ESD, Surge, over current, over voltage and undervoltage problems and have found nothing. I have protection devices on my board, as well as EMI filters for the data pairs. All other devices work normally, and if I do not unplug the device, all my software tools, and our commercial software operates without faults. It is only when you unplug (about 5% of the unplugs) that we get this fault.
I can see from the logs that the "Host" is sending the "RESET_PORT" command/call (or whatever is called) after it tried to SYNC_RESET_PIPE_AND_CLEAR_STALL with unseccesful results. I notice from the logs that this call is not made on the OK log, and simply calls for a device removal. The RESET_PORT call is issues on the HUB, which makes me think that the issues arises on the device driver.
The HUB IC is a standard TI part, and is already in mass production. My schematic follows their guidelines and our board layout was made by a design house in South California well aware of the critical importance of good practice for USB design.
Take a look at the following section of the 2 logs:
good disconnection:
and the bad disconnection:
The 10th column from left to right is the Endpoint column. On the good disconnection, the bulk transfer of 64 bytes has an Enndpoint address of 01:00:82, that is the Device's IN endpoint address. But on the bad disconnection, this is sent to FF:FF:8F, and I don't really dont know who or what that is.
My question basically is: Who is messing this up? The TI Hub? The Host? The device driver?
I did not design the device nor the device driver, I did the hardware design of the USB Hub using the TI part, and this prototype is working on a PCB we had manufactured. I would like to add that all other devices work fine, and I can hot-plug them with no issues, on this device is giving us this problem.
The thing about this device is that it has two stages. Stage one it identifies it the host as a bcdUSB 0x0110 device with one end point. One our application is loaded, the application loads the firmware onto the device on-the-fly and the device is re-enumerated, but this time it fails the WHQL by using a bcdUSB of 0x0101, and it now posses two endpoints, one IN and one OUT, in the logs you will probably see the addresses as 0x02 and 0x82, that is the device.
According to TI, they believe that the device driver is not handling the addressing topology of a USB Hub correctly, but I am unfamiliar with device driver design and do not know if this could be the actual problem.
Edit:
The other thing that I noticed is that after that last Bulk Transfer with 64 bytes on the GOOD disconnection, and 1024 bytes on the BAD disconnection that has different end points, there are 6 Internal USB get port status request on the GOOD disconnection, one of them is on the USB hub, but on the BAD disconnection no request is made on the hub whatsoever.
