• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 101 subscribers
  • Views 1923 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

USB flash drives with AM335x

Jeff Bencin
Prodigy 30 points
Other Parts Discussed in Thread: AM3358

Hello,

We are designing a product with the AM3358 that will be required to work with USB flash drives. My problem is that most of the ones I have tried fail with the AM335x, even though they work fine on my PC. So far I've only found one flash drive that works, although several other USB peripherals do work. I get the same results using u-boot or Linux.

HARDWARE: AM3358 w/ custom board
SOFTWARE: linux-3.2.0-psp05.06.00.00 and u-boot-2012.10-psp05.06.00.00, with buildroot userspace

Error messages in Linux...

[ 214.118499] usb 1-1: new high-speed USB device number 3 using musb-hdrc
[ 214.238494] usb 1-1: device descriptor read/64, error -71
[ 214.468475] usb 1-1: device descriptor read/64, error -71
[ 214.698486] usb 1-1: new high-speed USB device number 4 using musb-hdrc
[ 214.818481] usb 1-1: device descriptor read/64, error -71
[ 215.048675] usb 1-1: device descriptor read/64, error -71
[ 215.278503] usb 1-1: new high-speed USB device number 5 using musb-hdrc
[ 215.698486] usb 1-1: device not accepting address 5, error -71
[ 215.818481] usb 1-1: new high-speed USB device number 6 using musb-hdrc
[ 216.238494] usb 1-1: device not accepting address 6, error -19
[ 216.244415] hub 1-0:1.0: unable to enumerate USB device on port 1

In u-boot...

U-Boot# usb start
(Re)start USB...
USB: scanning bus for devices... No USB Device found
     scanning bus for storage devices... 0 Storage Device(s) found

Does anyone know why this might happen?

Thanks,

Jeff

  • 0
    TI__Mastermind 27890 points

    Hello Jeff,

    Could you describe the peripherals that DO work?

    How would you characterize the throughput performance of the single flash drive that does work?

    Could you describe the topology of your USB DP/DM traces? Do you have stubs, switches, chokes, caps, resistors, test-points, ribbon cables, etc., present on this signal pair?

    My initial suspicion is that you have a signal integrity issue that is preventing HighSpeed (thumbdrives) from operating correctly, while Low and Full-Speed devices (keyboards, mice, etc.) remain unaffected due to their much higher signaling voltage and lower bit-rates.

  • 0 in reply to -DK-
    Prodigy 30 points

    > Could you describe the peripherals that DO work?

    I've tried keyboards, mice, and USB-serial converters. All full-speed or low-speed devices, all work. As for the one flash drive that does work, it connects as high-speed, but there is nothing different from the other drives when I do "lsusb -v" on it (from my PC).

    > How would you characterize the throughput performance of the single flash drive that does work?

    I just tried copying some large files around.
    It took 1.6 seconds to copy a 20MB file of random data from the drive.
    It took 70 seconds to copy it back.
    I also frequently get errors when moving large files to and from the drive.
    I guess even this drive really doesn't work right.

    > Could you describe the topology of your USB DP/DM traces? Do you have stubs, switches, chokes, caps, resistors, test-points, ribbon cables, etc., present on this signal pair?

    I'm just the software guy. I'll let our hardware engineer respond to this.

  • 0 in reply to Jeff Bencin
    TI__Mastermind 27890 points

    Thanks Jeff.

    Your data reinforces my hypothesis that the issue at hand is signal integrity related. I'll watch this thread waiting for your HW guy to respond.

  • 0 in reply to Jeff Bencin
    Prodigy 80 points

    > Could you describe the topology of your USB DP/DM traces? Do you have stubs, switches, chokes, caps, resistors, test-points, ribbon cables, etc., present on this signal pair?

    The bottom of the PCB has a TPD4S012DRYR ESD device after about 150mils of differential traces beyond the USB connector. The top of the PCB has a ACM2012H-900-2P choke after about 150mils of differential traces beyond the USB connector. After the choke is about 350mils of differential traces into the AM3358.

    I made a test where I cut the traces on the bottom layer to remove any stub effects. I also removed the choke and jumpered with short AWG30 wires. Neither of these things helped the USB.

    Our application can easily afford to run USB at 12Mb/s if this is possible with Linux. Other than that I can offer our schematics and PCB gerber data.

    Thank you,

    Erik

  • 0 in reply to Erik Booth
    TI__Guru**** 167681 points

    The following patch will force MUSB work in full-speed mode, it clears HSENAB bit in POWER register in musb_start(). The patch is based on PSP 6.0.0.0, but I don't think you will have issue to apply it to 5.6.0.0.

    diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 075aa5f..758661e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -962,7 +962,6 @@ void musb_start(struct musb *musb)
 
        /* put into basic highspeed mode and start session */
        musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
-                                               | MUSB_POWER_HSENAB
                                                /* ENSUSPEND wedges tusb */
                                                /* | MUSB_POWER_ENSUSPEND */
                                                );
  • 0 in reply to Bin Liu
    Prodigy 30 points

    That patch worked, we can at least use the USB drives in full-speed mode now. Thanks.

  • 0 in reply to Jeff Bencin
    TI__Mastermind 27890 points

    I'm happy your interface is up, but the fact that limiting the interface to FS mode made it work, means that poor signal integrity is almost certainly root cause.

    This document from the USB-IF has some good information regarding best-practice system design concerns for High-Speed USB. You may want to review it (and the checklist at the end) with an eye toward design decisions made on your board.

  • 0 in reply to -DK-
    Prodigy 80 points

    DK,

    I read through that doc and I think we followed these design techniques very closely. We have many high speed designs that work properly including USB 2.0, FireWire, and SDI video running at 3Gb/s. We have controlled impedances specified in our PCB stackup and routed these very short USB 2.0 traces with arcs. I also have a picture from an oscilloscope showing a very clean eye diagram of this USB 2.0 signal. I know I can't rule out a hardware issue but I am hard pressed to figure out what it is right now.

    If we can pursue this further I will greatly appreciate the help.

    Thank you,

    Erik

  • 0 in reply to Erik Booth
    TI__Mastermind 27890 points

    Erik,

    A couple of things:

    - First: can you double check your entire USB clocking tree? I've seen issues before where our "programmed" (expected) input clock is different from the actual input clock which resulted in bit errors at HS but not LS/FS. 

    - Second: any chance you can borrow/rent a USB Electrical Compliance rig? This is comprised of a scope with the USB Electrical Certification package installed and a USB break-out board (SQUIDD). This ten minute test would answer many questions.

  • 0 in reply to -DK-
    Prodigy 110 points

    DK,

    Your thought of checking the clock tree got us to review clock related items - thanks.  I want to post what we finally did to fix these USB issues so that someone else may benefit. 

    I fixed the problems with USB for both u-boot and linux.  The short version of the story is that I needed to set the #define V_OSCK to the oscillator value we are using (25 MHz) in uboot’s include/configs/am335x_evm.h file.  It had been set to the eval board value (24 MHz).  We are using the AM335X SDK 05.06 eval board code as a template.  
    When you look at uboot's /arc/arm/include/asm/arch-am33xx/clocks_am33xx.h, you can see that the USB Phy clock is derived directly from V_OSCK.  So I can see why we experienced USB problems within u-boot. 
    But it looks to me like linux gets the system oscillator value by reading the 2 assigned sysboot pins, then adjusts all the clock-related fields dynamically at startup (including setting the peripheral PLL register values, needed to generate the USB Phy clock).  We did have these pins set correctly for 25 MHz.  And at linux startup the console log showed a sys clock of 25 MHz.
    I am surprised that changing V_OSCK value in u-boot DID fix our linux USB problem, but also am glad that this issue is now fixed.