device reset not 'seen' by hub?

[beethoven]

Looking for general advice and pointers....

I have a custom USB device that has a SMSC 2.0 hub with two connected devices, call them A & B, both running at full speed(1.1). The SMSC hub connects to the host at high (2.0) speed.

General operation all devices work.... but.... Problem occurs when new firmware is sent to device A and, after programming (with a delay of 5 seconds) device A releases it D+ line 1.5k pull-up to indicate a reset and then re-asserts the D+ line pull-up.

Reset/re-enumeration failure conditions:
* If device B is attached (which is constantly sending data all the time... uses about 30% of the USB 1.1 bandwidth)

Reset/re-enumeration failure conditions:
* If device B is NOT attached
                and/or
* a USB 1.1 only hub is connected between the SMSC hub and the host

From the USB sniffer data (Beagle 480) and o'scope captures of d+/d- it appears that device A is properly released the d+ pull-up, but the SMSC hub does not 'see' the activity and never reports it to the host.

I attached a o'scope capture of the d+/d- lines during the reset on Device A. The data packets seen goes away if you remove device B (and the reset works).

Any thoughts, pointers, help is appreciated. Thanks in advance.

- Beethoven


[attachment deleted by admin]

[Jan Axelson]

Removing the pullup doesn't indicate reset; it emulates device detachment. Maybe the device isn't remaining detached long enough for the host to receive the status-change message.

Jan

[beethoven]

The device A drops the d+ pull-up for about 200ms.

[Jan Axelson]

A protocol analyzer will show the status-change messages from the hub, if any.

Jan

[Barry Twycross]

This counts as a "fast replug" (its the equivalent of unplugging the device and immediately plugging it back in), its one of the most difficult things for a host to cope with, it causes all sort of hassle with your port state machines. We recommend if you're going to detach you do it for at least 500ms, if not a whole second.

[beethoven]

@ Barry and Jan - Thank you! I am still looking into this.

New question: Does the hub give any indication if a downstream port generates and SE0 event? I suppose what I am driving at is this: Can I see (using a sniffer or scope) 1) if a hub recognizes an SE0 event and 2) the release (end) of an SE0 event?

- Beethoven

[Jan Axelson]

An SE0 may signal an EOP, Disconnect, or Reset. Why do you need to know?

Jan

[beethoven]

I have a high-speed hub on a custom PCB with two (full-speed) downstream devices. I need to have one device (on occasion) program itself with new firmware. The programming process requires to re-enumerations on the USB bus. The first enumeration always works (not hardware?). However the second enumeration usually fails...

From scope captures of the reset event, it is clear that the D+ and D- lines both drop to below 0.8V easily for 2.5us. (Actually more like 50us), yet all the indications are that the hub 1) does not recognize the SE0 or 2) it recognizes the SE0, but handles it either in a way software does not expect.

Thus the gist of my question is: Can I confirm the hub 'sees' the second SE0 event? If I can, then I can focus on the host and see if it is handling the event and if the re-attachment is working properly. As I said, all the indications are the hub is missing what appears otherwise to be an SE0 event.

One salient footnote: the other USB device uses a serial port driver and is constantly being pinged by the host (got data? got data? got data?). When this second device is removed, the 2 re-enumerations are always successful.

- Beethoven

[Jan Axelson]

On detecting a disconnect, the hub returns a status-change indicator on its interrupt endpoint. Also see the Get_Port_Status request.

See 11.12.4 and 11.24.2.7 in the USB 2.0 spec.

Jan

[beethoven]

According to your book (p 75) it says, "... interrupt endpoints must wait for the host to request data before sending data."

What I think I understand is that when the hub sees an event on a port, it needs to wait until the host asks (via hub status request) if anything has changed? Do I understand correctly?

What I see.... on a 'good' capture, I will see a 'hub status' request indication a change on port X, but on a 'bad' capture, I do not see a 'hub status request' at all.

If the host is supposed to send the 'hub request' and I don't see it in the USB capture, then the host is at fault? If the hub is supposed to alert the host to the change with a 'hub request' then the hub is at fault?

As I read your book, is looks like the host is not sending the request. yes? no? 

- Beethoven

[Jan Axelson]

The host sends interrupt IN token packets at least as often as the endpoint's maximum latency value.

To be safe, have the device maintain the "removed" state long enough for the host to learn about it.

See Barry's comment above.

Jan
 

[beethoven]

I have confirmed that the host is sending the request to the hub asking for status changes every 40ms. I also confirmed that when the process works, the hub reports a change on port 1. When the process fails, the hub NACKs the host request, though it ought to indicate a status change. Thus, it seems clear that the hub IC itself is not recognizing the SE0 event.

We had code that allowed for 200ms, 500ms and 1200ms of disconnect, and I can only say that sometimes the hub worked and sometimes not. Usually not, however, even with 1.2 seconds of disconnect. From looking at the scope captures, I cannot understand why the hub IC is missing the SE0 event: clearly, there are many windows when the D+ and D- lines are below 0.8V for at least 2.5us. (This is seen on multiple devices, so it is not a particular IC.)

I also added 22 Ohm resistors in series with D+ and D- to no avail (though the bus at this point is full-speed).  Adding 10pF (or even a scope probe) to D+ often did very much improve the results, but not 100%, more like 80% improvement.

The HUB IC is not, I believe, going into suspend mode. According to the manufacturer (SMSC), it takes 100-150us for the hub to 'see' an SE0 event if it is in suspend mode. I say this for two reasons: 1) the host continually sends SOFs (according to the capture) every 125us and 2) there is a pin on the part which should change state when in suspend mode, and it does not change state.

Any suggestions for searching for the hub's 'missed SE0' explanation? Thanks!

-Beethoven

[Jan Axelson]

Are the devices detachable? If so, see what happens when you physically detach and reattach.

Also no harm in trying longer delays, 2 secs., 5 secs, to see what happens.

Jan

[beethoven]

Hi Jan,

I did try the 5-second disconnect, to no avail. However, on the 13th, I received an e-mail from the hub IC manufacturer (SMSC) wherein they say, "The USB2513B hub needs 100us of SE0 to detect a FS disconnect."

Since, attached to the hub, is a second USB device still active, there is rarely 100us of 'quiet time' for the SE0 event to be detected. The only solution would be to somehow disable the second USB device communications during the disconnect.

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

I have sent a number of e-mails and made phone calls over the last 2 weeks to SMSC with no responce. I have asked them if this meets the USB spec (which, to me, it does not) and if there are any work-arounds.  My speculation is that this is a bug in the silicon.

I will update this later if/when I get more/final details.

- Beethoven

[beethoven]

I will also note that the proposed fix is, "It would be natural to stop USB traffic to the device after sending a proprietary disconnect command. Then the hub will see the disconnect."

In otherwords, the software must terminate all communications to all the devices on the hub when an SE0 event is sent upstream. In our application, this is not impossible since we know when to expect an SE0 event (during firmware re-program). But I just do not see this as practical in most applications.... is this called out for in the USB spec?

- Beethoven