TUSB2036: Schematic design review

Hi Danilo,

Are there 15K pulldowns on the downstream ports?  Does the host see the hub connection?

Regards,

JMMN

Hi JMMN,

Thank you for your response. Here is the feedback of our customer.

15k pulldowns resistor are present as you can see on the attached file (resistors are in the component U3 : https://www.mouser.fr/datasheet/2/761/SEMT_S_A0000305173_1-2575604.pdf).

And there are also 22ohm series resistor.

Yes the host sees the hub (there is a mistake on my schematic, the reset pin is not attached to anything except a test point so i shorted the pin with 3V3).

Regards,

Danilo

Hi Danilo,

The hub will need an actual reset pulse after 3.3V goes high.  Can you try adding a capacitor / pullup resistor to the reset pin?

For the downstream devices, do you see PWRON/ outputs get asserted?  Is the suspend pin high?

Regards,

JMMN

Hi JMMN,

We received this response from our customer,

As indicated in my previous message, the reset pin issue has already been fixed.
The PWRON get asserted.
Let me explain again: the hub is perfectly working so the issue is not the hub not working.
The problem is that on my board, there is two usb port:
-One device port that makes the board act as a usb device (like a printer, or a keyboard)
-One host port where the hub is attached to.

When plug in the usb device on my computer it's well recognized but once the usb hub is mounted on the PCB, the usb device cannot enumerate anymore and that's the issue.

Regards,

Danilo

HI Danilo,

Where is the USB device being connected to when it cannot enumerate?  Is it possible that the VBUS is drooping (below 4.5V) and causing enumeration issues?  The TUSB2036 is configured as a 2 port hub with permanently connected devices, that looks correct based on the schematic.

USB hubs can only be connected to a USB host on their upstream port (DP0/DM0), the other ports only support device connections.

Regards,

JMMN

Hi JMMN,

Here is the response of our customer.

VBUS is not dropping, i have already checked that.
Then, i've never say that i'm try to use the TUSB2036 as a USB device.
let me explain once again.
This is a System on module from microchip.
ww1.microchip.com/.../SAMA5D2-Series-Data-sheet-ds60001476F.pdf
On it there is ONE single USB DEVICE AND ONE USB HOST.
My problem is that i need two USB host, that why i'm using a hub.
As i said already, the hub is working but the USB device is not working because of the hub, and the first question i asked in the ticket was about the implementation of NPINTx and NP3 pins because i don't understand the "permanently attached" thing.
One host is just a usb connector and the other one is a hardwired UBLOX LISA U2 module.
I do not understand the permanently attached thing, because i could permanently attached a usb host like a keyboard in the usb connector. This is where i'm very confused.

Regards,

Danilo

Hi Danilo,

NP3/ pin enables or disables Port 3 of TSUB2036 - in this case it is disabled.

NPINTx pins set if the ports are permanently attached or not.  Permanently attached means that there is a device hardwired to the port - so that it will always be there.  Unattached ports are exposed connectors where maybe a device is connected, maybe it isn't.  Functionally, it will not have much system impact.

So the customer SoC has 1 host port  and 1 device port.  The customer connects the TUSB2036 to the host port of the SoC, creating 2 host ports from the 1 host port.   This all works, correct?  The problem is that the SoC device port doesn't work when the hub is used?  If that is the case, it is likely a SoC software issue.

Hi JMMN,

We have received this feedback from our customer.

Yes that's the problem.
One of my device is hardwired (but not yet populated on the board).
Why would that be a software issue?
On the eval board, there is a usb hub and there are no issues reported.

Regards,

Danilo

Hi Danilo,

I wouldn't expect the NPINT pin settings to impact system functionality, but it is possible that the host software is looking for a device connected downstream of the hub and hanging when it doesn't find one.

What is the enumeration error that is being reported?  Can they probe the DP/DM lines on the failing connection?

Regards,

JMMN

Hi JMMN,

Here is our customer's response.

"I wouldn't expect the NPINT pin settings to impact system functionality, but it is possible that the host software is looking for a device connected downstream of the hub and hanging when it doesn't find one." : So we agree that the issue could be related to hardware and not software?

"Can they probe the DP/DM lines on the failing connection?"
Probe these lines but to see what? What am i looking for?

The error displayed on windows is : Unknown USB Device (Device Failed Enumeration).

According to the USB ch9 documentation, the USB DEVICE is stuck in the state "DEFAULT" (once again, only when the USB HUB is fully wired. If i open the D+ or D- line of the USB HUB UPSTREAM port, the USB DEVICE will not fail enumeration).

Regards,

Danilo

Hi Danilo,

If the hub works properly, but it causes another port on the system to which it is in no way connected to fail, that would be a software issue, not a hardware issue.

Please confirm that the issue is that when the TUSB2036 is installed the connection shown in red no longer works?  If that is the case, they should contact Microchip for support.

Hi JMMN,

According to our customer,

I confirm the issue is that when the TUSB2036 is installed the connection shown in red no longer works.

"If the hub works properly, but it causes another port on the system to which it is in no way connected to fail, that would be a software issue, not a hardware issue."

Actually, as said in the datasheet of the sama5d2 series MPU, USB device and host port are shared, so they are not completely separate as shown here:

Regards,

Danilo

The connection between the ports is within the Microchip product, TI cannot help debug that.  If the customer can provide DP/DM plots of the failed enumeration we may be able to provide more information on the issue but not the root cause.

Regards,

JMMN

Hi JMMN,

Here is our customer's response.

I only have a 25Mhz oscilloscope at my disposal so i won't be able to provide any plot of DP line.
Then, TI is saying that the problem is coming from microchip but microchip (been discussing with them for two months) says that the problem is coming from TI.
Do you have TUSB2036 eval board to provide? So i could plus into the Microchip eval kit to see if i still have this issue.

I have checked the product page and I understand that the EVM is already obsolete.

Regards,

Danilo

Hi Danilo,

No, we don't have any eval boards for this device.

Can the customer share why the Microchip team believes this is a hub issue?

Regards,

JMMN

Hi JMMN,

This is what microchip said about the hub : " Also, did you check with Texas Instruments for the hub implementation? I think the implementation should be verified by them as well, I briefly checked and I am not sure about the consistency in NP3/NPINT0/NPINT1 assignment, as well as tying pins DP3 and DM3 to ground. Could you please check it?"

Regards,

Danilo

Hi Danilo,

The customer can try setting the NPINT0/1 pins to 00, but functionally the hub will work either way.

Regards,

JMMN

Hi JMMN,

According to our customer,

I probed D+ line of the USB device while the hub was enumerated and while the hub was not enumerated.
The results are in the files below with the timing.
What i can guess seeing this and reading the USB spec, the host is resetting the device and then it's enumerated (when the hub is not powered) but when the hub is powered, the HOST reset the device 3 times and then fail the enumeration. The timing are not even the one i should expect.
And also, i probed the D+ line of the usb device when the hub is being enumerated and it doesn"t toggle at all.
We can guess that the issue comes from the driver provided by linux.

Capture_USB1_ENUMERATED

Capture_USB1_NOT_ENUMERATED

Regards,

Danilo

Hi Danilo,

Yes, it appears that the USB device is not completing the high speed handshake with the hub is connected or responding as a FS device so it keeps getting reset.  This behavior is not caused by the hub.

Regards,

JMMN

Hi JMMN,

Our customer has further clarification below.

Not sure to understand.
If the USB device respond as a full speed device it Can not enumerate ?
While debugging the Linux driver, I saw that when the device was enumerating, it was enumerating as a USB high speed and when not working, it was enumerating as a full speed device.
What's the difference regarding my issue?

Regards,

Danilo

Both HS and FS devices enable a pullup on DP, if the HS handshake completes properly then the host knows a HS device is connected.  When a device does not complete the HS handshake correctly but has a pullup on DP, then the host will assume it is a FS device.