device reset not 'seen' by hub?

[Barry Twycross]

Far as I can tell, this 100us requirement does not meet the USB spec.  (I thought 2.5us was spec.)

The spec I can see is in table 7-2 in sec 7.1.7.1. it says:

Disconnect(at downstream port)         SE0 for ≥2.5 μs

That looks like a lower bound to me, disconnect can not be detected if the SE0 is less than (or equal to) 2.5µs. The SE0 has to be greater than 2.5µs and it doesn't say what the upper bound on the time is.

[Barry Twycross]

We use a lot of SMSC hubs in our products, and I've never seen a problem with traffic on one port disabling disconnect detection on an adjacent port. Are you totally sure you're pulling the lines down correctly? Have you verified that with a scope?

When a device disconnects the lines aren't driven low, they just have nothing to pull them up, so the weak pull downs on the hub's port drag it to SE0. Driving SE0 could possibly be sending it to a different level which isn't recognized. Can you tristate your output drivers rather than turn them on? That should look like a disconnect.

[Barry Twycross]

Do you configure the hub as single or Multi-TT.

We configure them as multi-TT, that way traffic from an adjacent port wouldn't disturb the unplug. With multi-TT operation full speed traffic is not broadcast.

I just tried to recreate your problem, I couldn't. I had constant traffic going to one port and unplugged a device from an adjacent port. There was no visible delay (on a CATC) of the port seeing the disconnect. There were no 100µs gaps in the traffic to the adjacent port, though there was a 59µs gap at the end of the frame. It'd be difficult to arrange traffic which doesn't at least have the odd gap of 60µs or so.

[beethoven]

Hi Barry,

OK. I agree that the lower limit is 2.5us. Good Point.

We have another system using the SMSC USB2514B which showed the same behavior as our custom board... that is... when we plugged in directly to this other hub design the two devices under test (our implementation of the 2513B was not involved) and tried a disconnect, it failed in the same manner.

I believe we are using the multi-TT because the default (for this part) is to have multi-TT 'True' (MTT_ENABLE) and we are not using the EEPROM to set it to anything other than the default value.

You can see the scope trace on my first post of this thread. Both D+ and D- pull to within, say, 50-100mV of ground. As I understand the spec, they both need to be under 800mV to be a valid SE0.

WRT tri-stating output drivers.... we have tried tri-stating the output to the P-mos with the pull-up, but this did not help.

Perhaps try this.... On your set-up, try disconnecting several times in succession. Our first disconnect ALWAYS works. It is the second disconnect which usually fails.

I appreciate your help!

- Beethoven

[Barry Twycross]

What's the traffic to device B? I can't work out how you'd get a traffic pattern like that.

[Barry Twycross]

The traffic does look like the hub is in single TT mode though.

To get the hub into multi-TT mode, the right alternate setting has to be made to the hub. On ours the multi-TT alt is always the second alt, so its not the default.

[beethoven]

Hi Barry,

The traffic on the second device is a USB<->SERIALCOM -- that is, the USB device shows up as a comm port. The COMM driver continually hammers the USB bus asking for data from the device. The USB device simply NACKs unless it has data. In real life, this device would have a data rate of maybe several bytes per minutes with a time-sensitivity of, oh, say 250ms. 99.99% of the time there is no data to return. So the request rate is unreasonably high.

If you ask, isn't there a better way? Or can the requests rate be reduced? I will agree with you... but the external vendor who controls the driver and their device firmware has argued that this would be a non-trivial matter. Certainly, when this device B is not present, the HUB perfectly recognizes the SE0 event from Device A every time.

As for the single-TT... Perhaps I am wrong, but here is how I see that matter:

We are using the USB2513B with no EEPROM. They are stock ICs, no special modifications for our application.

According to the datasheet, the device does have a multi-TT available. Whether it operates as a single-TT or Multi-TT is decided by Register x06, bit 4 "MTT_ENABLE" (page 38). Checking for the default (factory) value, register x06 is '9B' (page 35). From this, bit 4 is '1' indicating 'One TT per port'. I do not believe this can be overridden by a configuration pin, nor without an external EEPROM. So if it appears to be operating as a single-TT, I could not explain why.

Why do you suspect it is operating in single-TT mode? Are you aware of any ways to force single-TT operating that I might be missing?

 - Beethoven

[Barry Twycross]

All the Multi-TT hubs I've come across, including the SMSC ones we use default to single TT operation, I'm pretty sure its specced that way. The hub driver has to specifically select the Alt interface which is multi-TT to put the hub into multi-TT mode, it has to issue a Set_Interface command to the device with the right alt. Is your hub driver doing that?

Why I say the scope plot looks like single TT mode is that you're seeing traffic to the adjacent port while the device is trying its detach. I assume the traffic is to the adjacent port, that's what you're complaining about. A single TT hub will broadcast traffic to all ports, a multi-TT hub will only send traffic to the port its destined for. So either your hub is in single TT mode, or the device's driver hasn't stopped trying to talk to the device.

How big is the max packet size on the serial device? When I tried the experiment to see if I could reproduce your problem I had 2 devices with a 64 byte maxpacket naking constantly. I still had a 59µs space at the end of the frame because the controller has to allow time for a 64 byte response. It looks like you're getting the same pause. What was unusual about the traffic is its showing 8 transactions, presumably NAKs, then a pause. I've never seen a pattern like that. What host controller are you using?

[beethoven]

Hi Barry,

According to the attached screenshots, it does not appear that the SMSC Hub is in single-TT mode. (I am assuming that the Device Descriptor indicates current operation... maybe it only indicates potential capabilities?) I checked all the 'set hub' and 'clear hub' commands and I do not see anything changing the TT usage.

Max packet size in the serial device is 64.

We have an external vendor doing the host, so I do not have easy access to the source. But I can ask to about the 'alt interface' if you still think it is a question. Host Controller is Marvell PXA168.

- Beethoven

[attachment deleted by admin]

[Barry Twycross]

The attached screen shots don't say one way or the other if its in single or multi-TT mode. They're listing both alts. IF 0 (alt 0) and IF 0 (alt 1). If nothing's done a set interface, then its going to be in single TT mode.

Its not "set hub" and "clear hub" you need to be looking at, its Set_Interface.

[beethoven]

Hi Barry,

I do not see any "Set Interface commands" send to the Hub. So if the hub requires this to operate in multi-TT mode, then this is not occurring.

However, when I looked at table 11-14 in the USB spec, it says for 'Set Interface', "Undefined. Hubs are allowed to support only one interface."

Also, I e-mailed the SMSC tech support with this question; "... Does the multi-TT feature operate from power-up? Or does the hub default to single-TT and requires a ‘Set Interface’ command  to switch to multi-TT?"

The answer: "By default the hub is in MTT."  

This also supports my earlier assertion that the hub is in multi-TT mode because the datasheet indicates the default register setting for "MTT ENABLE" is set to true.

Is there any other way I can verify the hub is in single TT mode (or not)? The evidence I see supports a multi-TT mode, but your experience says otherwise.

It sure would be cool to find the 'silver bullet' to fix this problem. But at least I presumably have a 'brute-force' approach of shutting down the busy device B communications.

- Beethoven

[Pat Crowe]

Weird. Table 11-14 does seem to say that. But read '11.23.1 Standard Descriptors for Hub Class'. This describes the behaviour which Barry mentioned, and is followed up with sample descriptors showing multiple interfaces. I suspect that, as the original spec was altered to include High Speed and Multi-TT hubs, not every reference was updated. There is also a reference, at the start of 'hubs', to the device tree working completely as a bus, with all devices seeing all transactions, which is not true with multi-TT hubs.

[beethoven]

To Sergey (who asked) and anyone who wants my final thoughts on this matter:

Unfortunately, we never did 'solve' the problem other than to have the whole device power cycled. Long story, but given the our relationship with client and other vendors, best we could do in the time allotted.

The real problem seems to lie in the USB spec wherein the dataline must be 'quiet' for 2.5us to 2000us to detect the reset, but data can continue to fly on the datalines (to a different device on same hub) much more frequently than 2 seconds -- so the 'quiet time' may never be seen.

All the components (hub, target device, other hub device) are conforming to spec, it is the spec that fails. (Kinda like the 'tiny j' phenomena)

In our case, we had a second device on the hub which was driven by a USB-Serial driver in Linux. The driver (very inefficiently) was pinging the second device at a high rate (~20us) asking "got anything" to which the 2nd device responded "no". Meanwhile, the USB hub was waiting for 100uS of 'quiet' (meeting USB spec) and could not see it due to the ping rate of the second device. (if 2nd device was removed, everything worked perfectly.)

Fixes (in order of elegance and reverse order of practicality)
1) USB spec changes to declare by fiat that the 'quiet time' to detect a reset request is X, such that X is faster than space between potential communication packets.
2) The linux driver be changed to slow down the ping rate. Even a ping rate of 250ms would have been sufficient. (Vendor was unwilling to change the driver)
3) Force hub to operate at USB 1.1 instead of 2.0 (required an external EEPROM which was not on PCB)
4) Have linux box suspend pings for second device at critical time (linux box software vendor unwilling to change code)
5) Have linux box reset the power to the specific USB channel when stuck (stuck time was predictable but linux box software vendor unwilling to change code)
6) Have end customer power cycle entire device when USB stuck (stuck time was predictable. *sigh*)

That is the whole nut in a thingshell.   

- Beethoven

[Jan Axelson]

Thanks for letting us know. Sorry you couldn't find a better resolution.