• State Resolved
  • Locked Locked
  • Replies 26 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 10995 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.

Linux/AM5728: USB2 test patterns through Hub

Michael Doyle
Intellectual 705 points
Part Number: AM5728
Other Parts Discussed in Thread: TUSB8041

Tool/software: Linux

Hi all. This could be user error, meaning I just need to write to a couple of registers, or it could be something wrong with my design. I'll paste a screenshot of the schematic below.

Basics: I connected USB2 to a TUSB4041, which drives three USB mini-B jacks. Non-standard, I know, but the system has space constraints. It basically works - we can connect thumb drives to the jacks, transfer data, etc. I want to do some testing to check the eye diagram, jitter, etc. At the test facility, we couldn't get the test patterns to appear at the jacks. I can get the 5728 USB port into test mode using the debugger as directed here: http://processors.wiki.ti.com/index.php/Linux_Core_DWC3_User's_Guide#USB_2.0_Test_Modes. When queried, the processor then reports it's in the mode commanded. However, we don't see the test patterns at any of the jacks. Do we need to do something to tell the processor to route the test pattern to a particular 4041 output?

If I recall correctly, the 5728 did not detect that the test fixture was plugged into a jack. I feel like that's part of the problem, but I don't know why we can detect a thumb drive but not detect the tester. Thoughts?

This might need to be referred to USB experts.

Schematic:

Many thanks!

MADman

  • 0
    TI__Guru**** 393215 points
    Hi,

    The USB experts have been notified. They will respond here.
  • 0
    TI__Mastermind 27890 points
    This is a function of the hub. Moving this to the support group for TUSB4041.
  • 0
    TI__Guru* 76130 points
    Hello,
    I would like to see the complete schematic, but anyway, since the USB devices works fine behind the hub I don't think there is a hardware issue.

    I think what is happening is that the test packet is being sent downstream the Processor's port but not downstream the TUSB4041, you have to make the TUSB4041 to send the test packets downstream.
    There is a windows tool provided by the USB-IF to do that, you can download it from here
    www.usb.org/.../

    There is also a document talking about how to do it in linux here
    www.linux-usb.org/.../

    Regards
  • 0 in reply to Elias Villegas M.
    Intellectual 705 points
    Thanks for you reply, Elias.
    The TUSB4041 connects to an AM5728 - no Windows involved.
    The Linux link looks promising, but appears to be sending its own test patterns, not putting the 4041 into test modes. Or am I missing something?
    Cheers!
    MADman
  • 0 in reply to Michael Doyle
    TI__Guru* 76130 points
    I've never used the linux version, I recommend you to send en email to admin@usb.org and they can point you in the right direction.
    Regards
  • 0 in reply to Elias Villegas M.
    Intellectual 705 points
    I emailed them, thanks. Didn't somebody in TI apps have to go through something similar to bring up the TUSB4041 eval board?
    MADman
  • 0 in reply to Michael Doyle
    TI__Guru* 76130 points
    We always use the USB-IF tools for windows as those are the tools used in the certification workshops, I've found more information here
    http://testusb.com/EHHS.html
    Regards
  • 0 in reply to Elias Villegas M.
    Intellectual 705 points

    The pdf describing the test method clicked for me. I've emailed the test house I'm using to see if they were using the PID VID method (I'm thinking some specialty scopes should have this built in by now, or built into the scopes' accessories). If they were, then I need to know why enumeration failed. If they weren't, then maybe we can try that.

    Would the TUSB4041 be responding with test patterns, or would the host be doing the responding?

    I'll return to this thread when I get some answers from the test house.

    Thanks! MADman

  • 0 in reply to Michael Doyle
    TI__Guru 60870 points

    There are two ways to get test packets from the downstream ports of the hub:

    Force the hub to pass through a test packet generated by the host using a USB Test_Force_Enable command.  Please be aware that this test packet may not pass USB HS SQ eye diagram testing.  The signal quality mask is expecting a test packet that is being generated by the port the test hardware is attached to, not a repeated test packet.

    Force the hub to generate a test packet on a downstream port using USB Test_Packet command for that specific port.

  • 0 in reply to JMMN
    Intellectual 705 points
    Hi all

    The PID VID approach didn't work. The driver recognizes that the test fixture is plugged in, and enumerates correctly, but still no test patterns.

    So, JMMN, can you provide a little more detail as to how I would deliver Test_Force_Enable or Test_Packet commands to the hub? I'm working with a Linux command line on a UART debugger.
  • 0 in reply to Michael Doyle
    TI__Mastermind 27890 points

    Hi Michael,

    1)      Ensure that ALL Linux USB PM is disabled. When in doubt, insert something into a hub port not under test to keep the upstream link from suspending.

    2)      Download and build the CONTROL.C utility located here into your Linux image: https://gitorious.org/usb/usb-tools/source/747ef6547d84b6db45ba8b005ee1e56fe5faa80a:control.c?p=usb:usb-tools.git;a=summary.

    (NOTE: My Linux guru tells me that this should be built on the target and not cross-compiled on the host)

    3)      Run the following at the Linux command line: “./control -t 0x23 -r 0x03 -v 0x0015 -i 0x04nn -l 0x00 -c 1 -D 0x0451:0x8044” where ‘nn’ equals the port to be tested.

    This should result in the TEST_PACKET being output. Let me know...

  • 0 in reply to -DK-
    TI__Mastermind 27890 points
    For your convenience:

    ./control -t 0x23 -r 0x03 -v 0x0015 -i 0x0401 -l 0x00 -c 1 -D 0x0451:0x8044
    ./control -t 0x23 -r 0x03 -v 0x0015 -i 0x0402 -l 0x00 -c 1 -D 0x0451:0x8044
    ./control -t 0x23 -r 0x03 -v 0x0015 -i 0x0403 -l 0x00 -c 1 -D 0x0451:0x8044
    ./control -t 0x23 -r 0x03 -v 0x0015 -i 0x0404 -l 0x00 -c 1 -D 0x0451:0x8044
  • 0 in reply to -DK-
    TI__Mastermind 27890 points
    EDIT: Noticed that NOTE: regarding cross-compiled was missing from original post.
  • 0 in reply to -DK-
    Intellectual 705 points
    Thanks, DK. I'm the HW guy, so building SW isn't my thing, but I'll ask SW for their help. Is there a way to tell if control.c is already built in? Asking because I think a contractor we worked with may have done the building already.
  • 0 in reply to Michael Doyle
    TI__Mastermind 27890 points
    You're asking another HW guy. ;)

    You could try to run the command on your image and see if it executes. I checked and it doesn't appear to be built in to our Linux SDK (OS image).
  • 0 in reply to -DK-
    Intellectual 705 points

    lol. I tried it on our normal image and got a message like "control is not found". I'm flashing with the image the contractor left me on an SD card. Maybe she built it into that.
    Failing that, I'll get a build made.
    I wonder why it's not part of the SDK? When would you NOT do electrical test on a new PCB?

    EDIT: Nope, not in the test build either.

  • 0 in reply to Michael Doyle
    TI__Mastermind 27890 points
    The SW guys try to keep the SDK to a reasonable size, so it's rare that a test app makes the cut. In this case, only designs implementing a hub would require the app so it's even harder to justify its permanent inclusion.
  • 0 in reply to -DK-
    Intellectual 705 points

    OK, progress! 'control'./control -h didn't work at first, but I stumbled into a couple changes to the dash options that were needed.
    At some point, I did a lsusb:
    root@am57xx-evm:~/usb_test_mode# lsusb
    Bus 003 Device 003: ID 05e3:f11d Genesys Logic, Inc.
    Bus 004 Device 001: ID 1d6b:0003 Linux Foundation
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation
    Bus 003 Device 002: ID 0451:8142 Texas Instruments, Inc. TUSB8041 4-Port Hub
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation

    "ah ha" say I. The PID was wrong. So I fixed that. At the same time I realized the bus number needed to be 03 instead of 04. (Two of the buses don't actually exist in the AM5728). So the commands needed should be:

    ./control -t 0x23 -r 0x03 -v 0x0015 -i 0x0301 -l 0x00 -c 1 -D 0x0451:0x8142
    ./control -t 0x23 -r 0x03 -v 0x0015 -i 0x0302 -l 0x00 -c 1 -D 0x0451:0x8142
    ./control -t 0x23 -r 0x03 -v 0x0015 -i 0x0303 -l 0x00 -c 1 -D 0x0451:0x8142
    ./control -t 0x23 -r 0x03 -v 0x0015 -i 0x0304 -l 0x00 -c 1 -D 0x0451:0x8142

    So I went all drastic, cut open a USB cable and hooked up a scope (I don't have any sort of test fixture). I thought I saw the diff signals wiggle once when I ran the command on port 1, but I haven't seen it since. Does it need to have a device on the other end to work?

    What happens now is I enter the command, and it returns with a prompt. If the signals wiggled, I missed it. When I enter a second time, I get an error message:

    root@am57xx-evm:~/usb_test_mode# ./control -t 0x23 -r 0x03 -v 0x0015 -i 0x0301 -l 0x00 -c 1 -D 0x0451:0x8142
    root@am57xx-evm:~/usb_test_mode# ./control -t 0x23 -r 0x03 -v 0x0015 -i 0x0301 -l 0x00 -c 1 -D 0x0451:0x8142
    control message failed --> -9
    root@am57xx-evm:~/usb_test_mode# [ 1730.448919] usb 3-1-port1: Cannot enable. Maybe the USB cable is bad?

    Last thing: Enter the command once and just wait, making sure the error message wasn't the result of a timeout. After waiting a minute or so, I'm guessing it's not going to do anything.

    What behavior should I be expecting?

    UPDATE: I didn't have the scope trigger set right. After a reset, the first run of the control command results in a 100mV pulse that decays somewhat slowly, followed 80us later by a 60mV pulse that appears to be much shorter. When I send the command again, short pulses about 33us apart appear. As I repeat sending the command, these two scenarios alternate.

  • 0 in reply to Michael Doyle
    TI__Mastermind 27890 points

    Right, the PID and topology (bus numbering) I pasted represents a different TI hub on a different (non-TI) board (BeagleBone X15 in this case).

    Your 'lsb' doesn't show the SS root hub instantiated.

    Here's mine:

    root@am57xx-evm:~# lsusb
    Bus 002 Device 002: ID 0451:8140 Texas Instruments, Inc.
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 002: ID 0451:8142 Texas Instruments, Inc.
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

    Which version of our SDK are you using?

  • 0 in reply to -DK-
    Intellectual 705 points

    SDK 3.0.2

    I don't have a hub on the USB3 - it goes straight to an 'A' jack. When I plug in a colleague's USB3 drive, it enumerates. In fact, we're able to get USB3 testing going at the lab. So for the moment, I'm not too concerned about that bus.

  • 0 in reply to Michael Doyle
    TI__Mastermind 27890 points
    Ahhh...I see that now. I mistakenly assumed this was a SS hub.

    At this point I'm going to need our USB SW guy to look into this. I'll forward this thread.
  • 0 in reply to -DK-
    Intellectual 705 points

    Continuing with what I saw on the scope: are those pulses I saw part of a handshaking process? The USB cable I was probing was only connected at my board's jack; it was open at the far end - no USB device connected.

  • 0 in reply to Michael Doyle
    TI__Mastermind 27890 points

    No, doesn't sound like it.

    My SW guy is building an image for me now. I hope to repro today.

  • 0 in reply to -DK-
    TI__Mastermind 27890 points
    OK, I have it working now.

    I used the following commands to test the three downstream ports on AM572x GP EVM:
    control -t 0x23 -r 0x03 -v 0x0015 -i 0x0401 -l 0x00 -c 1 -D 0x0451:0x8142
    control -t 0x23 -r 0x03 -v 0x0015 -i 0x0402 -l 0x00 -c 1 -D 0x0451:0x8142
    control -t 0x23 -r 0x03 -v 0x0015 -i 0x0403 -l 0x00 -c 1 -D 0x0451:0x8142

    This EVM uses the same processor+hub you are.

    The problem was that the -i (index) parameter of the CONTROL.C utility is referring to the USB protocol 'wIndex' field content, not the USB bus number. The utility is smart enough to address the correct device when provided the VID:PID, so nothing else in the command needs to change.
  • 0 in reply to -DK-
    Intellectual 705 points
    Well, that worked for a bit, then stopped working when I switched to another port. I tried power-cycling; no help, but maybe I have some other reset issue. I'm declaring issue solved.
    Is there a magic decoder ring to getting other test patterns out? Or is this the only one there is?
  • 0 in reply to Michael Doyle
    TI__Mastermind 27890 points
    Great! Don't forget to leave a thumb drive attached to one of the ports at all times or Linux may (will) suspend the hub.

    What other test patterns are you referring to? For USB 2.0, TEST_PACKET is the only pattern I'm aware of. There are other test modes (TEST_J, TEST_K, etc.), but these are for certification of the silicon itself rather than qualifying a PCB design.