2010-09-20 12:56 AM
hid behind a hub
2011-05-17 05:07 AM
That’s not supposed to happen. I suspect one of three causes:
(1) Defective hub (2) Operator error (3) Device software A defective hub is unlikely. Yes, code in hubs is complex but if it works well with other devices the chance that it somehow singles out your specific device is highly unlikely. I suppose that your device could be messing up a bus powered hub. That’s not likely because you should see serious malfunction effects. Operator error? It’s easy to try several things to get a new device to work. Sometimes one behaves in specific ways in order to placate some magical juju that’s out to get you. Think about device firmware timing relationships. There are timing differences when a another hub is in the path. (Almost certainly you are using a hub inside your computer. You don’t see it therefore “there is no hub involved.�?) The $400 Beagle USB monitor may be just what you need. to resolve your issue.2011-05-17 05:07 AM
Thank you for your suggestions.
First of all I want to add some info about the problem. We are developing two products with the same stm32f103zg: one of them is directly connected to the usb plug but the other has an hub (smsc USB2514), so the processor is connected to the hub and the hub is connected to the usb plug. The product with stm32 connected to the usb plug works well if attached to the pc but it does not work if connected to the hub on the pc's display. The product with an hub does not work. Using the debugger I can see that the packed sent from the pc (WriteFile) arrives but the ReadFile (overlapped) times out (the fw send the response!) I haven't understood the ''operator error'' part of your response. When you speak about timing, are you referring to some register on the stm32?2011-05-17 05:07 AM
The problem was the endpoint buffer: I have used 128 byte but it is wrong, the maximum size is 64