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 cascaded devices to create 10 downstream ports

Other Parts Discussed in Thread: TUSB2046B, TPS2044

Hello TI Team & Community,

I am using one TUSB2046B hub controller to talk to two other TUSB2046B hub controllers in order to create a total of 10 downstream ports.  I am, in effect, creating a 10-port self-powered hub.  I have reviewed the device datasheet, as well as the two reference schematics (motherboard implementation + self-powered implementation.)  I have also reviewed a number of the posts in this forum regarding this device.

I recognize that the schematic shown in the device datasheet is not a complete product schematic, and that you refer to the two reference schematics.  I do wonder about what looks like external "de-glitching" on the overcurrent signals between the TPS2044 power switch and the TUSB2046B hub controller as shown in the self-powered hub reference schematic.  The datasheet for the TPS2044 says that the /OC outputs are already de-glitched, providing 4 to 15 ms of delay.  Do I need to use the external RC nets, or can I reliably rely on the TPS2044 internal deglitching?

I have noted a number of threads discussing the required reset timing.  On the self-powered hub reference schematic, note 3 refers to a DS1233 reset IC - which doesn't seem to be present anywhere (?)  I see a 22 ohm resistor to 3.3V and a 100nF capacitor to ground on the reset - surely these values are not correct.  I have seen other values mentioned in the previous threads, and it seems that a 15k pull-up and a 1uF cap is correct - yes?

I am not sure about the purpose of the 2N3904 transistor circuit on the self-powered hub schematic.  It appears to be switched by the upstream VBUS, but beyond that, I don't understand what it is doing with the pull-up resistor R191 to DP, or why its collector is connected to the /RESET on the TUSB2046B and the CS on the EEPROM.  Can you please explain what is going on with all of this?

I also welcome any suggestions you might have regarding what I am attempting to do.  Thank you in advance for your assistance!

 

  • Hello,

    The de-glitching of the TPS device should be good enough.

    The datasheet specifies the timing requirements for the Reset# signal at power-on, you should choose the R and C values of the passive RC circuit to match these timing specs. We recommend to have a power-on reset pulse duration of 1ms to 4ms, you can achieve this with R=15K and C=0.1uF.

    I am not sure which schematic are you looking at, so I can't comment about a 2N3904, can you point me to the schematic.

    Cascading hubs is correct, you can have up to five tiers of hubs, you have to keep all the passive components on the downstream ports of every hub across tiers.

    Regards.

  • Hello Elias,

    The schematic is the TI reference schematic for the self-powered hub implementation.  I have attached it for your convenience, along with the reference schematic motherboard hub implementation.  I downloaded these from the TI website a few days ago.

    5850.2046B-PlainSelfPower.pdf1016.2046B-RefSch-HubonMthrBrd.pdf

    Thank you for your quick response - I am in the middle of schematic capture.

  • Hello,

    R187 value is indeed incorrect.

    The Q5 is used to activate the 1.5k pull-up only when there is a USB cable attached. 

    A 1.5k pull-up is required on DP by the USB spec, you may or may not use the Q5, if your application is an embedded hub I do not recommend using this Q5, connect the 1.5k directly to 3.3V instead.

    You can send your schematic for review once finished.

    Regards.

  • Hi Elias,

    Thank you for your offer to review the schematics - I will certainly take you up on this.

    I get that Q5 is switching the pull-up on DP only when VBUS is present, i.e., cable attached.  What I don't get is why the collector of Q5 isn't connected to the +3.3V supply, instead of being connected to the /RESET signal and its associated R & C.  Was the goal to only assert the DP pull-up after /RESET has gone false?  This seems questionable to me, unless there is something subtle and elegant going on that I am not catching.

    Thanks!

  • Hello Elias,

    I have the preliminary schematics for the product ready for you to review (thank you for this, by the way!)  What is the best way for me to get them to you?  Just attach them to a post here?  Thanks!

     

    Tom

  • You can post the schematic here, or if you don't want to make it public you can post your email address here and I will contact you by mail so you can email it me.

    Regards.

  • Hello Elias,

    My email is tspivey@sigmadzn.com

    Thank you!