• State
  • Locked Locked
  • Replies 30 replies
  • Subscribers 32 subscribers
  • Views 1288 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TUSB1210: TUSB1210 + TUSB8041 not appearing on embedded linux system

Zachary Porter
Prodigy 20 points
Part Number: TUSB1210
Other Parts Discussed in Thread: TUSB8041-Q1

I have a TUSB1210BRHBTQ1 USB2.0 phy connected to an embedded linux device and downstream of the USB phy I have a TUSB8041IPAPRQ1 2.0/3.0 hub connected. I'm trying to use the USB phy purely as a USB2.0 host but I've not been able to get the USB hub to show up on my system.

I am running Linux 4.14.0 and I keep getting the following error:

[    5.964905] usb usb1-port1: connect-debounce failed

All I see from lsusb are the linux root hubs:
Bus 003 Device 001: ID 1d6b:0002
Bus 001 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
Bus 002 Device 001: ID 1d6b:0003

Schematic snippet for the hub (VBUS has been modified from the drawing so that there is also a 90k resistor pulling the pin up to 5Vdc):

Schematic snippet for the USB Phy (The ID pin has been modified to be attached to GND to try and configure it as a host also VBUS is not connected to any voltage rail):

I've probed all of the voltage rails on each of the chips and everything looks fine, the clock signals are the correct frequency and look clean, and the resets are not being held active.

Any thoughts on how to best proceed in debugging or comments on the schematics would be very helpful.

  • 0
    TI__Guru 60865 points

    Hi Zachary,

    I don't see anything obvious in the schematics.  Can you probe on DP/DM and see what is happening?  When the hub exits reset, DP should go to 3.3V (FS pullup enabled).

    Can you send USBMON logs?

    Regards,

    JMMN

  • 0 in reply to JMMN
    Prodigy 20 points

    Here is a scope capture with the GRSTz (red) of the USB hub and the D+ (yellow) and D- (blue) for the upstream port.

  • 0 in reply to JMMN
    Prodigy 20 points

    As for getting a usbmon log, I'm only familiar with how to start a capture from userspace after I'm able to log into the console but presumably any issues between the USB phy and USB hub would be occurring before that point. Is there a good way to start usbmon logging before login to be able to capture the attempted transactions between the phy and hub?

  • 0 in reply to JMMN
    Prodigy 20 points

    Another scope capture with the same signals as before but also with the RESETB (green) signal from the USB phy.

  • 0
    Prodigy 20 points

    As an update, I tried adding USB to my u-boot configuration and device tree and I was able to intermittently connect to the USB hub like so:

    U-Boot>usb start
    starting USB...
    USB0: Register 2000440 NbrPorts 2
    Starting the controller
    USB XHCI 1.00
    scanning bus 0 for devices... 2 USB Device(s) found
    scanning usb for storage devices... 0 Storage Device(s) found
    U-Boot>usb info
    1: Hub, USB Revision 3.0
    - U-Boot XHCI Host Controller
    - Class: Hub
    - PacketSize: 512 Configurations: 1
    - Vendor: 0x0000 Product 0x0000 Version 1.0
    Configuration: 1
    - Interfaces: 1 Self Powered 0mA
    Interface: 0
    - Alternate Setting 0, Endpoints: 1
    - Class Hub
    - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

    2: Hub, USB Revision 2.10
    - A70408718053
    - Class: Hub
    - PacketSize: 64 Configurations: 1
    - Vendor: 0x0451 Product 0x8142 Version 1.0
    Configuration: 1
    - Interfaces: 1 Self Powered Remote Wakeup 0mA
    Interface: 0
    - Alternate Setting 0, Endpoints: 1
    - Class Hub
    - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
    - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

    However, I typically get the following response instead:

    U-Boot>usb start
    starting USB...
    USB0: Register 2000440 NbrPorts 2
    Starting the controller
    USB XHCI 1.00
    scanning bus 0 for devices... cannot reset port 1!?
    1 USB Device(s) found
    scanning usb for storage devices... 0 Storage Device(s) found

    Any idea why I'm intermittently getting the "cannot reset port1!?" error? It's also strange to me that I get occasional success in U-Boot but no success in Linux. I've done my best to eliminate poor solder joints from the problem through inspection and ohming out various pins (I've even tried pressing down on leadless packages).

    I'm pretty stumped and any help would be greatly appreciated.

  • 0 in reply to Zachary Porter
    TI__Guru 60865 points

    Hi Zachary,

    From the scope plot you sent when the hub is not enumerated, the USB 2.0 portion of the hub is acting as expected (it sees USB_VBUS and enables the pullup on DP), but the host isn't doing anything, it should do a bus reset.  It is like it missed the connection event.  Do you have any visibility into what the TUSB1210 is reporting?

    Also, I didn't mean to mark the ticket as resolved - that was an error.

    Regards,

    JMMN

  • 0 in reply to JMMN
    Prodigy 20 points

    As an update, I now see both the USB hub and a downstream USB device appear properly in U-Boot consistently, but I'm getting the following errors when my kernel is booting:

    [ 3.478034] usb 1-1: new high-speed USB device number 2 using xhci-hcd
    [ 3.610043] usb 1-1: device descriptor read/64, error -71
    [ 3.850049] usb 1-1: device descriptor read/64, error -71
    [ 4.090032] usb 1-1: new high-speed USB device number 3 using xhci-hcd
    [ 4.177924] random: crng init done
    [ 4.222047] usb 1-1: device descriptor read/64, error -71
    [ 4.462044] usb 1-1: device descriptor read/64, error -71
    [ 4.702032] usb 1-1: new high-speed USB device number 4 using xhci-hcd
    [ 4.708575] usb 1-1: Device not responding to setup address.
    [ 4.922054] usb 1-1: Device not responding to setup address.
    [ 5.134031] usb 1-1: device not accepting address 4, error -71
    [ 5.266029] usb 1-1: new high-speed USB device number 5 using xhci-hcd
    [ 5.272571] usb 1-1: Device not responding to setup address.
    [ 5.486053] usb 1-1: Device not responding to setup address.
    [ 5.698030] usb 1-1: device not accepting address 5, error -71
    [ 5.703873] usb usb1-port1: unable to enumerate USB device

    I can read the registers of the TUSB1210 successfully and I get the expected value of 0x51 for reg 0x00. Is there a particular register that would be most helpful for debugging?

  • 0 in reply to JMMN
    Prodigy 20 points

    Probing the registers in the TUSB1210 I get the following:

    0x04 FUNC_CTRL 0x45

    0x07 IFC_CTRL 0x00

    0x0A OTG_CTRL 0x27

    0x13 USB_INT_STS 0x08

    0x14 USB_INT_LATCH 0x08

  • 0 in reply to Zachary Porter
    Prodigy 20 points

    The above was obtained through linux, and I repeated the test from within U-boot (where the usb hub is showing up properly)

    0x04 FUNC_CTRL 0x40

    0x07 IFC_CTRL 0x00

    0x0A OTG_CTRL 0x27

    0x13 USB_INT_STS 0x08

    0x14 USB_INT_LATCH 0x08

    The only difference seems to be the FUNC_CTRL register.

    Specifically, Linux is set to high speed with the termination select enabled, while U-Boot is set to full speed.

  • 0 in reply to Zachary Porter
    Prodigy 20 points

    My last comment is actually reversed: Linux is setting to full-speed (XCVRSELECT = 0b01 = FS) and U-Boot is setting to high-speed (XCVRSELECT = 0b00 = HS)

  • 0 in reply to Zachary Porter
    TI__Guru 60865 points

    Can you check the Debug register?  When that HostDisconnect bit was cleared there should be an interrupt sent on the ULPI interface, this appears to work as expected on the Uboot configuration but not the Linux one.  Do you have any debug ability from the device connected to the TUSB1210?

    Regards,

    JMMN

  • 0 in reply to JMMN
    TI__Guru 60865 points

    The register values you reported do make sense based on the scope plot - the Linux one would still be in full speed if the hub pullup was on, but nothing else happened.  However, that doesn't match up with this debug output which seems to indicate the link got through the high speed handshake.  Can you check if when you get this kind of debug output if the DP/DM lines are toggling or if DP is just staying high?

    Zachary Porter said:
    [ 3.478034] usb 1-1: new high-speed USB device number 2 using xhci-hcd
    [ 3.610043] usb 1-1: device descriptor read/64, error -71
    [ 3.850049] usb 1-1: device descriptor read/64, error -71
    [ 4.090032] usb 1-1: new high-speed USB device number 3 using xhci-hcd
    [ 4.177924] random: crng init done
    [ 4.222047] usb 1-1: device descriptor read/64, error -71
    [ 4.462044] usb 1-1: device descriptor read/64, error -71
    [ 4.702032] usb 1-1: new high-speed USB device number 4 using xhci-hcd
    [ 4.708575] usb 1-1: Device not responding to setup address.
    [ 4.922054] usb 1-1: Device not responding to setup address.
    [ 5.134031] usb 1-1: device not accepting address 4, error -71
    [ 5.266029] usb 1-1: new high-speed USB device number 5 using xhci-hcd
    [ 5.272571] usb 1-1: Device not responding to setup address.
    [ 5.486053] usb 1-1: Device not responding to setup address.
    [ 5.698030] usb 1-1: device not accepting address 5, error -71
    [ 5.703873] usb usb1-port1: unable to enumerate USB device
  • 0 in reply to JMMN
    Prodigy 20 points

    In U-Boot

    0x15 DEBUG 0x00

    In Linux

    0x15 DEUG 0x01

  • 0 in reply to JMMN
    Prodigy 20 points

    To the best of my knowledge I don't have any debug options for the TUSB8041-Q1 since we don't have any of the I2C/SMBUS lines connected. If it ends up being necessary to add wires to those pins to help diagnose then that's a potential option.

  • 0 in reply to JMMN
    Prodigy 20 points

    Here is a screenshot of my scope when those errors are occurring during the kernel boot process. Yellow is D+ and Blue is D-.

  • 0 in reply to Zachary Porter
    TI__Guru 60865 points

    Ah ok, this scope plot matches up better with the debug statements.  I didn't check the time base on the previous scope plot to realize it just captured the initial DP pullup and not the later USB traffic, my mistake.

    Based on this scope plot, the USB HS handshake is completing successfully several times and some traffic is being exchanged between the host and the hub, but then the host doesn't get the data it is expecting from the hub, so it stops communicating with the hub and the bus goes to IDLE.

    The reported error is about the device descriptor but the hub is a hardware based design and will always return the same descriptors (they can be modified slightly by I2C/SMBUS but this isn't enabled in your system).  I was asking if you had any additional debug capability on the host side so we could figure out which exact command was failing, but it doesn't look like this is possible.  There isn't any debug capability on the hub.

    It looks like the host to hub electrical connection is fine, but there a few hardware things that could cause this:  check the clock input is running at 24 MHz, and check that the supply voltages to the hub are not drooping - the hub pulls a lot of power when it turns on.

    Regards,

    JMMN

  • 0 in reply to JMMN
    Prodigy 20 points

    Here is the clock input which looks pretty close to 24 MHz. (This is not captured during the USB transactions)

  • 0 in reply to JMMN
    Prodigy 20 points

    Here is the scope capture for the 3.3V bus during the USB transactions

  • 0 in reply to JMMN
    Prodigy 20 points

    Here is the scope screenshot for the VDD bus which we have set to 1.1V during the USB transactions.

  • 0 in reply to Zachary Porter
    TI__Guru 60865 points

    Ok, power and clock look ok.  Can you zoom in and confirm that the USB host is sending SOFs every 125 us?  You can check in either of these areas circled in blue:

  • 0 in reply to JMMN
    TI__Guru 60865 points

    Another debug idea, can you start usbmon and then force the hub to reconnect (either manually togggle GRSTz low or USB_VBUS low) and then get a capture of the traffic?  I'd like to see what the hub is reporting.

    Regards,

    JMMN

  • 0 in reply to JMMN
    Prodigy 20 points

    Here's another capture during the kernel boot when I'm getting the USB errors (D+ is yellow, D- is red)

  • 0 in reply to JMMN
    Prodigy 20 points

    Here is a zoomed in view after the first burst of activity after the reset (more or less the first blue encircled area from your previous drawing). Orange is the math function of CH1 - CH3. It looks like there are bursts of activity every 266 micro seconds or so instead of 125 micro seconds.

  • 0 in reply to JMMN
    Prodigy 20 points

    Here is a zoomed in view of one of those signal bursts occurring every 266 micro seconds and it has a duration of around 200 nano seconds. My probe and scope bandwidth is 1Ghz per channel and this capture has 12.5 GS/s per channel. I don't have a USB 2.0 protocol analyzer on the scope, but if it were necessary I could probably purchase the software from my oscilloscope vendor.

  • 0 in reply to JMMN
    Prodigy 20 points

    Results of a usbmon capture when the GRSTz is pulled low on the hub:

    ffffffc06c0bbc00 343184819 S Ci:1:001:0 s a3 00 0000 0001 0004 4 <
    ffffffc06c0bbc00 343184842 C Ci:1:001:0 0 4 = 00010100
    ffffffc06c0bbc00 343184850 S Co:1:001:0 s 23 01 0010 0001 0000 0
    ffffffc06c0bbc00 343184856 C Co:1:001:0 0 0
    ffffffc06c44d300 343292015 S Ii:1:001:1 -115:2048 4 <
    ffffffc06c44d300 343292042 C Ii:1:001:1 -2:2048 0
    ffffffc06c0bbc00 343738229 S Ci:1:001:0 s a3 00 0000 0001 0004 4 <
    ffffffc06c0bbc00 343738238 C Ci:1:001:0 0 4 = 01010100
    ffffffc06c0bbc00 343738243 S Co:1:001:0 s 23 01 0010 0001 0000 0
    ffffffc06c0bbc00 343738248 C Co:1:001:0 0 0
    ffffffc06c44d300 343844013 S Ii:1:001:1 -115:2048 4 <
    ffffffc06c0bbc00 343844022 S Ci:1:001:0 s a3 00 0000 0001 0004 4 <
    ffffffc06c0bbc00 343844029 C Ci:1:001:0 0 4 = 01010000
    ffffffc06c0bb000 343844088 S Co:1:001:0 s 23 03 0004 0001 0000 0
    ffffffc06c0bb000 343844096 C Co:1:001:0 0 0
    ffffffc06c0bb000 343912013 S Ci:1:001:0 s a3 00 0000 0001 0004 4 <
    ffffffc06c0bb000 343912021 C Ci:1:001:0 0 4 = 03051000
    ffffffc06c0bb000 343912028 S Co:1:001:0 s 23 01 0014 0001 0000 0
    ffffffc06c0bb000 343912033 C Co:1:001:0 0 0
    ffffffc06c0bb000 343978655 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
    ffffffc06c0bb000 343978747 C Ci:1:000:0 -71 0
    ffffffc06c0bb000 343978765 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
    ffffffc06c0bb000 343978827 C Ci:1:000:0 -71 0
    ffffffc06c0bb000 343978834 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
    ffffffc06c0bb000 343979005 C Ci:1:000:0 -71 0
    ffffffc06c0bb000 343979024 S Co:1:001:0 s 23 03 0004 0001 0000 0
    ffffffc06c0bb000 343979031 C Co:1:001:0 0 0
    ffffffc06c0bb000 344044015 S Ci:1:001:0 s a3 00 0000 0001 0004 4 <
    ffffffc06c0bb000 344044023 C Ci:1:001:0 0 4 = 03051000
    ffffffc06c0bb000 344044029 S Co:1:001:0 s 23 01 0014 0001 0000 0
    ffffffc06c0bb000 344044034 C Co:1:001:0 0 0
    ffffffc06c0bb000 344216009 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
    ffffffc06c0bb000 344216041 C Ci:1:000:0 -71 0
    ffffffc06c0bb000 344216055 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
    ffffffc06c0bb000 344216125 C Ci:1:000:0 -71 0
    ffffffc06c0bb000 344216144 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
    ffffffc06c0bb000 344216212 C Ci:1:000:0 -71 0
    ffffffc06c0bb000 344216223 S Co:1:001:0 s 23 03 0004 0001 0000 0
    ffffffc06c0bb000 344216230 C Co:1:001:0 0 0
    ffffffc06c1fae00 344284015 S Ci:1:001:0 s a3 00 0000 0001 0004 4 <
    ffffffc06c1fae00 344284024 C Ci:1:001:0 0 4 = 03051000
    ffffffc06c1fae00 344284030 S Co:1:001:0 s 23 01 0014 0001 0000 0
    ffffffc06c1fae00 344284035 C Co:1:001:0 0 0
    ffffffc06c1fae00 344456012 S Co:1:001:0 s 23 01 0001 0001 0000 0
    ffffffc06c1fae00 344456020 C Co:1:001:0 0 0
    ffffffc06c0bbc00 344456171 S Co:1:001:0 s 23 03 0004 0001 0000 0
    ffffffc06c0bbc00 344456179 C Co:1:001:0 0 0
    ffffffc06c1fae00 344524019 S Ci:1:001:0 s a3 00 0000 0001 0004 4 <
    ffffffc06c1fae00 344524027 C Ci:1:001:0 0 4 = 03051000
    ffffffc06c1fae00 344524033 S Co:1:001:0 s 23 01 0014 0001 0000 0
    ffffffc06c1fae00 344524039 C Co:1:001:0 0 0
    ffffffc06c1fae00 344590641 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
    ffffffc06c1fae00 344590726 C Ci:1:000:0 -71 0
    ffffffc06c1fae00 344590773 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
    ffffffc06c1fae00 344590813 C Ci:1:000:0 -71 0
    ffffffc06c1fae00 344590822 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
    ffffffc06c1fae00 344591006 C Ci:1:000:0 -71 0
    ffffffc06c1fae00 344591017 S Co:1:001:0 s 23 03 0004 0001 0000 0
    ffffffc06c1fae00 344591024 C Co:1:001:0 0 0
    ffffffc06c0bbc00 344656013 S Ci:1:001:0 s a3 00 0000 0001 0004 4 <
    ffffffc06c0bbc00 344656022 C Ci:1:001:0 0 4 = 03051000
    ffffffc06c0bbc00 344656027 S Co:1:001:0 s 23 01 0014 0001 0000 0
    ffffffc06c0bbc00 344656033 C Co:1:001:0 0 0
    ffffffc06c0bbc00 344828025 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
    ffffffc06c0bbc00 344828057 C Ci:1:000:0 -71 0
    ffffffc06c0bbc00 344828083 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
    ffffffc06c0bbc00 344828143 C Ci:1:000:0 -71 0
    ffffffc06c0bbc00 344828213 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
    ffffffc06c0bbc00 344828241 C Ci:1:000:0 -71 0
    ffffffc06c0bbc00 344828261 S Co:1:001:0 s 23 03 0004 0001 0000 0
    ffffffc06c0bbc00 344828268 C Co:1:001:0 0 0
    ffffffc06c1fae00 344896014 S Ci:1:001:0 s a3 00 0000 0001 0004 4 <
    f����?ffffffc06c1fae00 344896029 S Co:1:001:0 s 23 01 0014 0001 0000 0
    ffffffc06c1fae00 344896035 C Co:1:001:0 0 0
    ffffffc06c1fae00 345068014 S Co:1:001:0 s 23 01 0001 0001 0000 0
    ffffffc06c1fae00 345068022 C Co:1:001:0 0 0
    ffffffc06c1fae00 345068062 S Co:1:001:0 s 23 03 0004 0001 0000 0
    ffffffc06c1fae00 345068069 C Co:1:001:0 0 0
    ffffffc06c1fae00 345136015 S Ci:1:001:0 s a3 00 0000 0001 0004 4 <
    ffffffc06c1fae00 345136024 C Ci:1:001:0 0 4 = 03051000
    ffffffc06c1fae00 345136030 S Co:1:001:0 s 23 01 0014 0001 0000 0
    ffffffc06c1fae00 345136035 C Co:1:001:0 0 0
    ffffffc06c1fae00 345633926 S Co:1:001:0 s 23 01 0001 0001 0000 0
    ffffffc06c1fae00 345634034 C Co:1:001:0 0 0
    ffffffc06c1fae00 345635693 S Co:1:001:0 s 23 03 0004 0001 0000 0
    ffffffc06c1fae00 345635800 C Co:1:001:0 0 0
    ffffffc06c1fae00 345704014 S Ci:1:001:0 s a3 00 0000 0001 0004 4 <
    ffffffc06c1fae00 345704023 C Ci:1:001:0 0 4 = 03051000
    ffffffc06c1fae00 345706181 S Co:1:001:0 s 23 01 0014 0001 0000 0
    ffffffc06c1fae00 345706189 C Co:1:001:0 0 0
    ffffffc06c0bbc00 346201925 S Co:1:001:0 s 23 01 0001 0001 0000 0
    ffffffc06c0bbc00 346202033 C Co:1:001:0 0 0
    ffffffc06c0bb000 346209531 S Co:1:001:0 s 23 01 0001 0001 0000 0
    ffffffc06c0bb000 346209644 C Co:1:001:0 0 0
    ffffffc06c44d300 346211644 C Ii:1:001:1 -2:2048 0

  • 0 in reply to Zachary Porter
    TI__Guru 60865 points

    Ok this is a standard SOF packet, but it has to happen every 125 us or the hub will not work.  Can you check if it is consistently every 266 us?  Have you tried connecting anything else to this port and seeing if it enumerates?  I'm not sure if you have that capability or not.

    This is likely the issue, the host controller should be sending a SOF every 125 us.

  • 0 in reply to JMMN
    Prodigy 20 points

    I've reset the hub several times and zoomed in on the resulting signal at several different points and there is always a gap of around 266 us. Unfortunately, the data lines from the USB phy are routed directly to the upstream port of our USB hub on a PCB without very good test points to try and attach another device directly to the phy.

  • 0 in reply to JMMN
    Prodigy 20 points

    Any idea what could cause this? Is the USB phy generating the start of frame packets or is it the processor attached to the phy and the phy is simply doing the physical layer translation of the signals?

  • 0 in reply to Zachary Porter
    TI__Guru 60865 points

    It is the processor attached to the phy, the phy can't generate its own packets.  Some USB devices may be able to handle the oddly spaced SOFs, but not most.  I would be surprised if this issue hasn't come up before, there may be a workaround available.

    Regards,

    JMMN

  • 0 in reply to JMMN
    TI__Guru 60865 points

    Can you accept my friend request so we can have an offline discussion about the processor vendor?

    Regards,

    JMMN