• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 33 subscribers
  • Views 2185 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.

TUSB2046B and Freescale K60F

Daylond Hooper
Prodigy 50 points
Other Parts Discussed in Thread: TUSB2046B

I have a system I am developing where a TUSB2046B is permanently attached to my USB host processor, which is a Freescale Kinetis K60F. After digging around in vain in the firmware, I still can't get the hub to enumerate on the K60F.  I though the TI community might help me verify the circuit to remove hardware as a potential cause of my issues.  I have attached a portion of the schematic for reference.

As things stand, I'm not yet even concerned about the device side of things, since I'm not even getting the TUSB2046B to enumerate.  In the firmware, I drive RESET low then initialize the other devices, then drive it high to engage the hub. the SUSPEND pin is low once this occurs, and DP0 is driven high as I would expect for a full speed USB device. Am I off somewhere else in the circuit, though?

Thanks in advance.

  • 0
    Mastermind 7925 points

    Is the crystal resonating? I do not see capacitors.

    Regards,
    Maciej 

  • 0 in reply to MaciejKucia
    Prodigy 50 points

    Good catch! That's even in the datasheet, and somehow we missed it.  Somebody is making the mods now and I will get back to you this afternoon. Thanks!

  • 0 in reply to Daylond Hooper
    TI__Guru* 76130 points

    Hello,

    OVERCUR# inputs requires an external pull-up.

    Make sure you are following the power-up timing requirements for Reset# de-assertion.

    Regards.

  • 0 in reply to Elias Villegas M.
    Prodigy 50 points

    We have done the OVRCUR pull-ups, but they aren't reflected on the schematic because that was a mod we added recently. No overcurrent pins are low, so this seems to be fine now. 

    With the reset timing, the system (and MCU) powers up, then the MCU drives the reset low, initializes internal components, waits for some time (10 ms is where I left it), then drives the reset pin high. I had assumed this would be plenty of time to stabilize the clock and such, but I guess this is all irrelevant if the crystal isn't doing its thing correctly based on the caps. Is this reset timing reasonable? I see from the datasheet that it should be 100 us to 1 ms once Vcc hits 90%, and though I have set it shorter before, a longer reset pulse shouldn't harm things, right?

    The reset may, however, manifest in one of two ways: either it starts off with the reset low, then waits until the 10ms timeout after component initialization and goes high; or it starts high, gets to the USB reset pin setting (then driven low), and passes through the component initialization and the 10 ms timeout. Would this high-low-high be a problem? I wouldn't think so since I could reasonably drive the reset at any time, provided it's powered up and the clock has been running for at least 60 us.

    Long story short, I think the reset timing is fine (but please correct me if I'm wrong), and the OVRCUR pins are behaving correctly. Even with that, I am not getting the attach event from the hub, so I am guessing that the crystal caps may fix it, or there is something else wrong.  I'll know more in a few hours when I can get my hands on a board again and test it.

  • 0 in reply to Daylond Hooper
    TI__Guru* 76130 points

    Hello,

    10ms should be fine, don't go longer, a USB device should be able to communicate with the host within 100ms after power is applied.

    I also think the crystal issue will fix the problem.

    Regards.

  • 0 in reply to Elias Villegas M.
    Prodigy 50 points

    Great, then the crystal issue is at the top of my list. I'll cut back on the wait time since it is overkill. For reference, here's our "raw" (uncapped) crystal output:

    This is before any tweaks, and the USB component is not in use. Maybe it will be of some help.

  • 0 in reply to Daylond Hooper
    Prodigy 50 points

    Maciej and Elias,

    Thanks for the tips! Between them and some code tweaks, I managed to get the hub enumerating and detected on the MCU. Now I need to address some driver issues and get those PWRON pins to go low, but that is a problem for tomorrow.

    Thanks again!