TUSB2077 using a HID device

Hello Colin, 

     Are you following the specification for the Power-up sequence? Could you provide some scope captures of the power-up sequence showing RESET#, Vcc and XTAL?

On our TUSB2077A evaluation module board (5277.sllu190.pdf ) the pin RESET# is connected to a RC circuit (see the figure below)  and with this the reset is held low for somewhere within the range.  

Could you post the schematic?

Regards.

Sorry for the delay I was working on another part of this design.  I'm posting the schematic and I will work on getting you the signals.  USB_RESET goes directly to a GPIO on my microprocessor which holds the line low until power up is complete.

7840.USB.pdf

Here are RESET, Vcc, and Xtal as requested...

The yellow is RESET line held low by my microprocessor.  The scope was triggered to when RESET goes high.

The first image shows the Vcc in Blue at the time RESET goes high.

The Second image shows Xtal in Blue at the time RESET goes high.

Hello Colin,

Could you post a scope capture showing how long the RESET signal is low after the Vcc(3.3-V) rail reaches its 90%? 

The image below shows an example of a 1ms long reset pulse. As you can see, XTAL signal must be active during the last 60 μs of the reset window.

Regards.

Here is the reset line in yellow approximately 3.5 seconds after the Vcc reaches 90%

Thank You for Your Time,

Colin

I know my 6mhz Xtal looks like garbage but you can't make it look pretty at 2.50ms, but it is there for the last 60us before the reset is released.

Hello Colin,

Your reset pulse is too long, this condition can interfere with USB enumeration. This is typically an issue with embedded system applications.

I would suggest implementing a power on reset pulse of between 1ms to 10ms.

Regards.

So, can I leave the 3.5 second delay in and then put a second 1ms to 10 ms reset pulse in?  Or does the reset have to be let go 1ms to 10ms after 90% power regardless?

Thanks,

Colin

Any thoughts on #2 listed above?

Hello Colin,

The power on reset pulse of between 1ms  to 10ms is a device requirement. Anything longer than 10 ms can interfere with USB enumeration.

Regards.

After some work I was able to meet this device requirement.  Before my OS starts I let go of the reset line 2ms after the power reaches 90% with the clock going.  It is much better.  However, the TUSB2077A still doesn't enumerate 100% of the time.  After I do some more formal testing I will get you a good percentage.

I am not an expert on all USB Hub requirements.  Any suggestions on what I may be missing to make this better?

Thank you for your time on this issue.

Do you have anything on the following?

After my microprocessor and the TUSB2077 enumerate fine, I have a USBHID device enumerate correctly with my microprocessor through the TUSB2077.  When the reset of the USBHID device is pressed, the USBHID device will attempt to reattach to the microprocessor.  During the time the USBHID tries to reattach, the PORTDIS light goes red.  Any ideas why on power up this will work and not during a reset condition?

What causes the PORTDIS light to go red?

Thanks Again!

Colin

Hello Colin,

The PORTDIS output is controlled by the USB Host, the TUSB2077A  receives from the Host the instruction to disable the port in order to  force the device enumeration. 

Is the USBHID device is permanently connected?

Could you try to enumerate the hub without any device connected?

Connect your USBHID device directly to the host, to ensure that it works properly after the reset condition.

Regards.

Thank you for explaining how the PORTDIS is controlled.

And I will wire around the hub chip on one of my prototypes.  I like this suggestion.

Answering your questions...

The USBHID device isn't permanently connected.

With no device connected, I still see no enumeration at times.

Hello Colin,

Your HID device is not permanently connected. Hence in addition to Joel's suggestions, could you also try following to see what happens?

Once HID device is enumerated, press RESET button on that device. As you mentioned earlier, it is exptected that PORTDIS LED will turn red and device will not be enumerated again.
Now, simply just disconnect HID device and reattach it and see what happens.

Is PORTDIS LED still indicating red?
Is HID device enumerated again?

Regards,
Bhaumik

Sorry for the delay in replying.  Following these instructions:

Once HID device is enumerated, press RESET button on that device. As you mentioned earlier, it is exptected that PORTDIS LED will turn red and device will not be enumerated again.
Now, simply just disconnect HID device and reattach it and see what happens.

Is PORTDIS LED still indicating red? Yes
Is HID device enumerated again? No

I'm unclear on how disabling the port allows device enumeration? 

Hello Colin, 

Additionally, connect your USBHID device directly to the host to ensure that it works properly after the reset condition you mentioned before.

Connect the hub to a different USB host (PC or Laptop).

Could you provide some trace captures using a USB protocol analyzer between the host and the TUSB2077A when the USBHID device tries to reattach?

Regards. 

Sorry about the late response,  I've worked on this issue quite a bit from my last post.  I do have a couple questions that might help me resolve this issue.   

Working on question 2 from my original post....

Using the suggestion of bypassing the HUB chip helped. 

To verify this statement: Additionally, connect your USBHID device directly to the host to ensure that it works properly after the reset condition you mentioned before.

When I looked at the HID device connected to the processor directly.  It would not enumerate when reset was pressed.  This ruled out anything the hub chip was doing. 

So upon further investigation a previous version of my USB stack wasn't detecting a lack of the HID pipe caused by a reset.  By going to a more recent version of the USB stack it currently works without the HUB chip in line.

Now with the HUB chip in line...  The USB stack detects the reset by a corrupted data error.  When the HID reset is let go the HUB chip holds this corrupted data keeping the HID device from enumerating again.  So, I have to press the Reset a second time on the HID device to get it to enumerate properly.  I know the HUB chip is holding the corrupted data because I currently activate the reset on the HUB chip and the corrupted data is gone.  I can do this except for my first problem of the HUB chip only enumerates properly 95% of the time. 

So for this part of my project is there a way to clear the corrupted data on the HUB chip with some kind of command instead of resetting? 

More questions to follow on the HUB chip enumeration problem.

Thank You for Your Time,

Colin

A side note...

My company doesn't have a USB analyzer.  Any suggestions on a decent USB analyzer?  Keep in mind this is an onboard circuit.

Colin