• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 5934 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.

Linux/AM3352: Stability issue with TUSB2036 Hub

Garry Clarkson
Expert 4635 points
Part Number: AM3352
Other Parts Discussed in Thread: TUSB2036,

Tool/software: Linux

Team,

I am working with a customer gateway design that is based on the AM3352 and has a 3 port hub TUSB2036 device connected to USB0 which in turn is configured as Host only.

The requirement is to commission the eMMC flash using a USB mass storage device connected to one of the downstream hub ports mounted by u-boot for the target file system images etc.

We have the USB_DRVVBUS output connected to a USB switch to loop-back the VBUS to the AM3352 to satisfy the MUSB controller state machine but otherwise the TUSB2036 has downstream switches on each port and is configured as a self-powered hub.

There is a problem with u-boot first reliably detecting the downstream hub and second when the hub is detected then correctly enumerating USB MSD and USB Ethernet devices connected to the downstream hub ports.

With an external powered hub connected directly to USB0 (using a break-out cable bypassing the on-board TUSB2036) there is no issue with mounting connected devices, similarly

Our understanding is that the USB block has two checks for USBn_VBUS when acting as a Host. In order:
1) Ensure VBUS is not present prior to us asserting USBn_DRVVBUS (VBUS power switch control). The MUSB controller is dual-role capable so we need to ensure that VBUS isn’t already being provided prior to us doing so. This check can be overridden via SW for implementations that hard-wire VBUS to system 5V.
2) Ensure that VBUS is valid (>=4.4V) within 100ms of us asserting DRVVBUS. It is here to sense VBUS power switch OC as we don’t have a discrete pin for OC. This one cannot be overridden.

The TUSB2036 itself will apply a 1K5 pull-up resistor to USB_DP0 15ms after either a hard or soft reset to signal availability to the upstream USB0 port on the AM3352. It will then wait upto 3ms for the upstream controller to connect before transitioning to 'sleep' mode.

We see that VBUS goes down while u-boot USB hub code is attempting to configure hub and enumerate ports. Enabling debug makes it work (mostly) which still points at a timing issue. Still not clear whether the code is forcing VBUS down or the USB module is doing it internally.

It appears that there is a subtle timing inter-dependency when initialising the USB controller and the downstream TUSB2036 hub device.

Below is an extract from what u-boot reports, including the hub product text:

musb_lowlevel_init: DEVCTL = 19
musb_lowlevel_init: DEVCTL = 5D
_musb_reset_root_port: POWER = E0
_musb_reset_root_port: DEVCTL = 5D
scanning bus 0 for devices... New Device 0
_musb_reset_root_port: POWER = E0
_musb_reset_root_port: DEVCTL = 5D
set address 1
get_conf_no 0 Result 25, wLength 25
if 0, ep 0
##EP epmaxpacketin[1] = 1
set configuration 1
new device strings: Mfr=0, Product=1, SerialNumber=0
USB device number 1 default language ID 0x409
Manufacturer 
Product      General Purpose USB Hub
SerialNumber 
1 USB Device(s) found
scan end
       scanning usb for storage devices... 0 Storage Device(s) found
       scanning usb for ethernet devices... 0 Ethernet Device(s) found
=>

If Linux is booted serially then we consistently failing to boot Linux from USB with following as the last things logged:

[ 2.354562] Waiting for root device /dev/sda1...
[ 2.468822] usb 1-1: new full-speed USB device number 2 using musb-hdrc
[ 2.611069] hub 1-1:1.0: USB hub found
[ 2.614973] hub 1-1:1.0: 3 ports detected
[ 2.620276] musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in a_host (89, <AValid), retry #1, port1 00000107
[ 2.794761] usb 1-1: USB disconnect, device number 2
[ 3.718836] hub 1-1:1.0: activate --> -19
[ 3.998796] usb 1-1: new full-speed USB device number 3 using musb-hdrc
[ 4.140803] hub 1-1:1.0: USB hub found
[ 4.144696] hub 1-1:1.0: 3 ports detected
[ 4.428794] usb 1-1.2: new full-speed USB device number 4 using musb-hdrc
[ 4.531642] usb 1-1.2: not running at top speed; connect to a high speed hub
[ 5.372200] asix 1-1.2:1.0 eth0: register 'asix' at usb-musb-hdrc.0.auto-1.2, ASIX AX88772 USB 2.0 Ethernet, 7c:c3:a1:86:9a:4c

It doesn't seem to mount the mass storage device although it did find the ethernet adapter once on the second attempt.

We have tried inserting delays and holding the USB hub in reset until the MUSB controller has started however the connection and device operation is still very unstable.

Please can you comment on the correct initialisation sequence to use and any timing or driver sequencing dependencies.

Regards,
Garry

  • 0
    TI__Guru**** 393215 points
    Hi,

    What Linux version is this?
  • 0 in reply to Biser Gatchev-XID
    TI__Expert 4635 points
    Hi Biser,

    This is with the a recent ti-processor-sdk-linux-am335x-evm-03.02.00.05 (because that was state of the art at the time the development started) and the kernel is linux-4.4.32+gitAUTOINC+adde2ca9f8-gadde2ca9f8 (i.e. the kernel tree supplied with that SDK).

    Regards,
    Garry
  • 0 in reply to Garry Clarkson
    TI__Expert 4635 points

    Please see below a logic analyser trace stowing the state of the various signals associated with a failed connection attempt and subsequent VBUS drop-out scenario described above:

    Regards,

    Garry

  • 0 in reply to Biser Gatchev-XID
    Guru 13660 points
    Hi Garry,

    It is not a hard and fast rule to "Ensure VBUS is not present prior to us asserting USBn_DRVVBUS (VBUS power switch control)." Can you give a try by removing this logic ? Looks like there is delay in getting the VBUS voltage above valid VBUS level within expected time and hence VBUS error.
  • 0 in reply to Dwarakesh Radhakrishnan
    Prodigy 100 points
    Hi,

    Could you elaborate on "expected time"? VBUS reaches 4.4V in approx 1.9ms and full supply level (5.2V) in approx 2.4ms - I was led to believe that the window for a valid VBUS on Sitara was significantly longer than that.

    Regards

    Stu
  • 0 in reply to Dwarakesh Radhakrishnan
    TI__Guru**** 393215 points
    Garry,

    I have notified the USB experts. They will respond here.
  • 0 in reply to Dwarakesh Radhakrishnan
    TI__Mastermind 27890 points

    Dwarakesh R said:
    Hi Garry,

    It is not a hard and fast rule to "Ensure VBUS is not present prior to us asserting USBn_DRVVBUS (VBUS power switch control)." Can you give a try by removing this logic ? Looks like there is delay in getting the VBUS voltage above valid VBUS level within expected time and hence VBUS error.

    This is the default for device operation. The OS must be configured to skip this rule.

    The scope plot shows attempted enumeration. This wouldn't occur if the VBUS test had failed.

  • 0
    TI__Guru**** 172871 points

    Garry Clarkson said:

    Below is an extract from what u-boot reports, including the hub product text:

    musb_lowlevel_init: DEVCTL = 19
musb_lowlevel_init: DEVCTL = 5D
_musb_reset_root_port: POWER = E0
_musb_reset_root_port: DEVCTL = 5D
scanning bus 0 for devices... New Device 0
_musb_reset_root_port: POWER = E0
_musb_reset_root_port: DEVCTL = 5D
set address 1
get_conf_no 0 Result 25, wLength 25
if 0, ep 0
##EP epmaxpacketin[1] = 1
set configuration 1
new device strings: Mfr=0, Product=1, SerialNumber=0
USB device number 1 default language ID 0x409
Manufacturer 
Product      General Purpose USB Hub
SerialNumber 
1 USB Device(s) found

    Do you see the same log all the time?

    It shows the hub is detected and enumerated.

  • 0 in reply to Bin Liu
    Prodigy 100 points
    Pretty much. Some instrumentation in the code suggests that u-boot builds a list of the three ports on the hub to be probed, but VBUS has been removed before it gets as far as probing the hub ports.

    More interestingly, we have made some progress, but would like to know why it makes a difference. So first a little more background:

    Because the DRVVBUS/VBUS connection is a closed loop (i.e. it is purely for the benefit of the processor, and isn't actually powering the integrated hub device, which is permanently powered) our hardware guys simulated the VBUS ramp up using an RC network on the output of the 5V switch driven by DRBVBUS. This replicates the ramp up seen when VBUS has a large bypass capacitor (for in-rush current protection I understand - as per USB 2.0 spec which states minimum of 120uF).

    If I add a large bypass cap (happen to have 220uF) between VBUS and GND, it appears to allow u-boot to function correctly and fully enumerate all of the devices (well most of the time, occasionally it fails to spot the mass storage device, but it always finds the USB ethernet adapter - this may be the result of a known issue on the TUSB2036).

    So our questions are

    1. What is it about this cap which changes the behaviour (other than extending the VBUS ramp time from 2.5ms to 3.2ms to the full rail 5.2V)?

    2. Is this the actual solution?

    We don't see any glitching on VBUS without it, so seems unlikely it is a smoothing effect.
  • 0 in reply to Stuart Northfield
    TI__Mastermind 27890 points
    Stuart,
    1) The controller expects capacitance on VBUS as per the USB specification. For Host mode operation the minimum requirement is 120uF. This affects both HW and SW timing, which as you have pointed out earlier in this thread, appears to be suspect.
    2) Very possibly. Please add 120uF to USBn_VBUS and re-run your test. We are looking to see if this results in 100% enumeration of the hub itself.
  • 0 in reply to -DK-
    Prodigy 100 points

    OK, understood. With the 220uF cap on USB0_VBUS it improves functionality significantly and I am always seeing some hub downstream ports, but not always both of them (for the purposes of this testing, there is always a USB mass storage device in one port, and a USB Ethernet adapter in the second port. The third port is only brought out internally, and never has anything connected at the moment. This setup is a requirement for part of the factory test process which is performed within u-boot, so I'd like to bottom out why it is not 100% reliable now).

    What I observe is that u-boot always sees the USB Ethernet device, but sometimes does not see the USB mass storage device. If it fails to see it, it will consistently fail to see it until I unplug and reinsert the flash stick, and which point a fresh usb enumeration will see both devices again. I will try and gather further debug info to try and determine whether the mass storage device is ever indicated to the u-boot code in this scenario.

    The mass storage device states a bus power requirement of 100mA, the ethernet device states 250mA - neither of which are particularly taxing loads.

    Makes no difference if I swap the devices over between ports.

  • 0 in reply to Stuart Northfield
    TI__Mastermind 27890 points

    Stuart,

    Good to hear the TUSB2036 hub is now always recognized by the AM335x Host.

    Have you tried different USB mass storage devices downstream of the hub?

  • 0 in reply to -DK-
    TI__Expert 4635 points

    Hi Stu,

    for completeness we checked with the designers for the TUSB2036 and the TUSB2036 EVM. They comfirm that :

    • The series 27Ohm and 27pF caps to ground on the upstream DP and DM lines  are needed.
    • The Sitara AM3352 has internal pull-up/down 15K resistors (see the TRM section 16.2.2 Pullup/PullDown Resistors) so these must be omitted.
    • As previously mentioned the 120uF cap on upstream VBUS is also required

    Does a soft or hard reset of the TUSB2036 controller resolve the detection of the USB Mass Storage device?

    Regards,

    Garry