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

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

  • Hi,

    The USB experts have been notified. They will respond here.
  • This is a function of the hub. Moving this to the support group for TUSB4041.
  • 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
  • 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
  • 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
  • I emailed them, thanks. Didn't somebody in TI apps have to go through something similar to bring up the TUSB4041 eval board?
    MADman
  • 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
  • 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

  • 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.

  • 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.
  • 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...

  • 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
  • EDIT: Noticed that NOTE: regarding cross-compiled was missing from original post.
  • 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.
  • 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).
  • 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.

  • 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.
  • 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.

  • 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?

  • 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.

  • 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.
  • 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.

  • No, doesn't sound like it.

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

  • 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.
  • 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?
  • 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.