• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 806 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 Oscillator Output not working

Adam Garrison1
Intellectual 580 points

We need help with the TUSB2046BIVFRG4 in understanding what would make its oscillator output XTAL2 go low during boot-up of the LP20 (5% of the units on the line are doing this and we need to understand why).  The output normally takes a second to start oscillating and then stays oscillating

  • 0
    TI__Guru* 76130 points

    Hello,

    Possible root causes:

    1) A wrong power-up sequence, terminal GRST# should be de-asserted until the power rail is stable and the crystal is oscillating for a minimum of 60us.

    2) Wrong load capacitors value, see Figure 6 of datasheet.

    3) The hub is going into suspend, if there is no upstream connection the hub will enter the suspend state, if there is no downstream connection the USB Host may send the hub into suspend(after 3ms of no bus activity).

    4) Power drop, if the voltage goes below its minimum limits the oscillator will stop.

    Regards.

  • 0 in reply to Elias Villegas M.
    Intellectual 580 points

    In our application it takes more than 4ms for the 6MHz hub X2 to begin oscillating, and the experiment of reducing its crystal load capacitance and series resistor resulted in a delay of 2ms for X2 to begin oscillating.   TI’s datasheet recommends to hold the hub in reset up to 1ms so we selected 0.6ms and had problems on 24 out of 430 assemblies so far (there was no downstream communication received from upstream even though the hub was not in suspend mode – problem corrects itself after automatic warm boot of the application).  The solution found with sample size 4 out of 4 assemblies including the problematic hubs, is simply to increase the power on reset time to 10-12ms and that way the oscillator is 100% stable when reset is de-asserted.  Swapping the hub from a problem board to a non-problem board moves the problem from one board to the other.

    We are a highly regulated business seeking objective evidence to explain our finding about the TUSB2046 USB hub.  Now we know what appears to fix the problem (delaying de-assertion of reset until long after 6MHz oscillation is stable – e.g. 10-12ms) and have no need for TI to disclose proprietary workings of the hub, but we need help to explain why what we did corrected the behavior?  Again 95% of the hubs in our application have no problem with a reset occurring at 0.5ms, which is prior to the clock X2 oscillating.

    The core question is why 95% of TI's hub chips work fine in our application.

     

    Adam