• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 32 subscribers
  • Views 2215 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.

TUSB2046 Enumeration of Ports fails on first run

Gustavo Litovsky1
Prodigy 70 points
Other Parts Discussed in Thread: TUSB2046B, TPS2041B

we are experiencing issues that appear to be due to the TUSB2046B. 

We have an embedded processor running a USB stack connected to a TUSB2046B, all one a single board. When first running the processor, the USB stack runs and initializes, enumerating the TUSB2046B. However, it fails to enumerate a mouse and a keyboard connected to it (even if we connect and disconnect them).

Without restarting the board, I restart the debugger and rerun the whole software and USB stack. This reinitializes the USB stack and now both the TUSB2046B hub as well as the mouse and keyboard enumerate.  Just like the gentleman in the following post (2nd from the top), it seems the TUSB2046B seems to toggle the PWRON line for 100ms:

http://e2e.ti.com/support/interface/digital_interface/f/130/t/117140.aspx

The fact that PWRON is triggered on the second run (with the same software) and not on the first is indicative that something else is going on, since the keyboard and mouse only enumerate on the run when this happens. However, I have already removed the TPS2014B switches and hardwired 5V to the two ports, bypassing the TPS2041B switches that were in place. This didn’t seem to help.

Just to confirm:

1)      Power Sequence is followed as you and other have explained. I have verified it. In fact, the delay in the pulse was 2ms, I lowered it to 300us to 400us just in case it was causing the issue by taking too long.

2)      Crystals and everything else seems to be good (we can enumerate and run after the second run).

3) Although not shown in schematic, we have added 15k pulldowns on both DM and DP, as well as 1.5k pullup on DP. (These changes allow the hub to function properly).

The question is whether the PWRON is related, what is causing it to happen, and how would it affect enumeration of the two devices connected to it.

Schematic should have been provided to you.

Further information:

Using a USB protocol analyzer in between the TUSB2046B and a mouse I've been able to observe the following:

1) On the first run, the TUSB2046B seems to suspend the mouse, so nothing enumerates and nothing happens. Pin 32 of TUSB2046B is LOW, indicating TUSB2046B is not actually suspended itself.

2) On the second run of the processor (without removing board power), the host connects, then suspends (event 8), but then restarts the device, keeps alive, enumerates and works.

Regards,
Gustavo

  • 0
    TI__Mastermind 18655 points

    Hello Gustavo,

    What is the     value of the C567 capacitor?

    Verify the USB lines have 90ohm differential impedance. Populate 22pF edge control capacitors from DP/DM to ground. 

    Can you check the status of the SUSPEND output and OVRCURn/ input?

    On OVRCURn/ input a 10kΩ pullup is     recommended.

     

    Regards.

  • 0 in reply to Joel Jimenez0
    Prodigy 70 points

    Hi Joel,

    1) I cannot find this capacitor in the schematic. Where is it connected

    2) We will try to verify 90 ohm and populate the capacitors to see if they help.

    3) Suspend is always Low (as I noted in my update above). The active low overcurrent is always high since I removed U31 and U33 and there is a pullup on each. Basically power is always connected and the device isn't told if there is overcurrent.

    We will also weaken the pullup to 10k (although it is not an issue currently).

    However, why would the device enter suspend? It seems to me since we can get communications running, that physically everything is OK, but something with the device initializing requires the USB stack to hit it twice for the TUSB2046B to issue a reset for the downstream devices.

    Regards,
    Gustavo

  • 0 in reply to Gustavo Litovsky1
    Intellectual 345 points

    Hello Gustavo,

    Your problem seems interesting and strange also. I would like to see if I can give some feedback.

    Would it be possible for you to share here data which you captured during first run as well as during second run on Protocol analyzer? I would like to observe difference between Hub class specific requests being served during first and second run. Also if possible please re-capture these data by connecting only single device. In this way, we could reduce requests to be observed.

    Have a Nice day!

    Bhaumik

  • 0 in reply to Joel Jimenez0
    Prodigy 70 points

    Hi Joel,

    I see that the schematic you received was the newer version with the fixes we incorporated.  C567 is a 1uF capacitor. For testing I have also tried replacing it with 0.22uF capacitor to generate the reset below 1ms but above 100us (just in case we needed to be up before other devices).

    Below is the Beagle 480 capture between the TUSB2046B and the mouse, showing both runs.

    1220.USB_capture_1st_and_second.zip

  • 0 in reply to Gustavo Litovsky1
    TI__Mastermind 18655 points

    Hello Gustavo

    Could you provide some trace capture using a USB protocol analyzer between the host the     TUSB2046B?

    Enumerating the hub :
    1. A mouse connected to it.
    2. Without any device connected to it and then connect a mouse.

    Regards.

  • 0 in reply to Joel Jimenez0
    Prodigy 70 points

    Hi Joel,

    Unfortunately this is not possible. The TUSB2046B is hard wired to the processor.  Physically it would be challenging to try and cut the traces and connect the analyzer.

    All the traces I provided are downstream between the hub and a device connected to the downstream port.

    I have attached another capture. In this case, I ran the host processor and the stack without mouse, then connected it. I disconnected again and connected again. You can see that it went to suspend.

    Then I ran the processor for a second time (without powering down). Only in this case did the mouse enumerate and work.

    The Hub is USB 1.1 and it seems mouse enumerates as Low Speed device.

    3782.USB_capture_mouse_2_disconnects_then2ndrun.zip

  • 0 in reply to Gustavo Litovsky1
    TI__Mastermind 18655 points

    Hi Gustavo,

    Could you apply a hard reset (pulse on the RESET/ pin of the TUSB2046B) instead run the processor for second time?

    Could you ship one of your platform for debugging?

    Regards.

  • 0 in reply to Joel Jimenez0
    Prodigy 70 points

    Hi Joel,

    I was under the impression that the TUSB2046B reset pin could not be used for resets during operation, and that it only supported a 100us to 1ms reset pulse on startup. I will issue the reset and see.

    As for sending the platform, I will have to inquire whether it is possible.


    Regards,
    Gustavo

  • 0 in reply to Joel Jimenez0
    Prodigy 70 points

    Joel,

    Please see image attached. Restarting the device doesn't seem to do much.

    I see Reset/TargetDisconnected and Reset/keepalive/Target Disconnected.

  • 0 in reply to Gustavo Litovsky1
    TI__Mastermind 18655 points

    Hello Gustavo,

    Any updates on this?

    In answer to your question:
    "The question is whether the PWRON is related, what is causing it to happen, and how would it affect enumeration of the two devices connected to it."

     The USB host controls the port power of a USB hub using the SET PORT FEATURE (PORT POWER) and CLEAR PORT FEATURE (PORT POWER) commands, these commands cause the TUSB2046B to assert or deassert the PWRONz  outputs.  These commands are automatically by the USB driver loaded on the USB host.  The power commands are sent during system power on / off, reboot, sleep and resume as needed.  They will also be sent during overcurrent conditions.  

    Regards.

  • 0 in reply to Joel Jimenez0
    Prodigy 70 points

    Hi Joel,

    Performing resets does not seem to have any effect.

    I have prepared the hardware and it should be sent to you.

    Regards,
    Gustavo

  • 0 in reply to Gustavo Litovsky1
    Intellectual 345 points

    Hello Gustavo,

    You already have sent your hardware to TI team for debugging purpose and you will get some feedback from that team soon.

    But I am also little bit curious about this. Thanks for capturing and sharing log files from protocol analyser. But unfortunately I do not have software installed for that protocol analyser. Hence I can not open those TDC files. And as it is not possible for you to connect Protocol analyser between host and hub, we might not be able to observe initial hub class specific requests sent from host before device on down-stream port is connected. Anyway, would it be possible for you to convert those TDC files ( you uploaded earlier ) into PDF format and share here?

    And one more thing: USB mouse is Low speed device. Have you checked whether this same thing happens with some Full speed device or not? You can check by connecting mass storage stick. Please connect only one device for this testing.

    If you are busy and would like to wait from TI response before trying this than also it would be fine.

    Warm Regards,

    Bhaumik

  • 0 in reply to Gustavo Litovsky1
    TI__Mastermind 18655 points

    Hi Gustavo,

    Please send me an email (joel.jimenez@ti.com) so I can give you a shipping address.

    Regards.