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

TUSB8041A: Disable internal pull-down (!?) on I2C line

Mark Beuvink
Prodigy 85 points
Part Number: TUSB8041A
Other Parts Discussed in Thread: TPS55288, INA230, TPS65987D, , TAS5805M, TUSB8041

Hello,

The I2C pins 37 & 38 have an internal pull-down resistor of min 14.5k. This requires a low-impedance pull-up resistor to achieve enough high-level.

On the other hand, the pull-up resistor impedance must be high enough in order to be pulled low. For this device low level is 0.4V @4mA and there are some other devices (in my system) that are even more limited in drive capability.

This limits the range of pull-up resistors just to get DC operation OK, for sure over a range of conditions and some series resistance due to switches, connectors and cabling in a system.

Is there any way to disable these pull-down resistors? We are configuring the device from an MCU so not with an EEPROM. This is because of BOM & testtime cost.

Kind regards,

Mark

  • +1
    TI__Guru 60870 points

    Hi Mark,

    Unfortunately no, there is no way to disable these pulldowns.  What features are you enabling via SMBUS/I2C?

    Regards,

    JMMN

  • 0 in reply to JMMN
    Prodigy 85 points

    That's a pity, but then we will have to design around that.

    We use some other TI IC's which also have a 'not so good' I2C hardware implementation. The drivers should be able to pull low with significant current (~10mA) and low level threshold should be high enough. However using these IC's on the same bus is nearly impossible -DC- wise so we willl probably have to add some I2C buffers...

    TI IC's in the design:

    Device     Vil_max   Vih_min    "Output impedance"  Output spec
    TPS55288   0.4       1.2        25                  Not specified. Using INT output
    INA230     0.99      2.31       133                 0.4V @ 3mA
    TPS65987D  0.99      2.31       133                 0.4V @ 3mA
    TUSB8041A  0.8       2          100                 0.4V @ 4mA + 14.5k pull down
    TAS5805M   0.99      2.31       330                 0.2VDD = 0.66V @2mA

    So in this case:

    • TUSB8041A requires a low impdance pull up to pull above 2.31V.
    • TAS5805M requires a high impdance pull-up to enable pulling the data line low enough
    • TPS55288 requires a significant low level.. well below the capabilities of the TAS5805M

    Thankfully the slaves do not need the acknowledges of their peers..

    Use of I2C on this device:

    - swap some of the USB 2.0 lines for better layout

    - would also like to use it to change the name when enumerating in windows,we have multiple hubs in the product and having names would be easy for debugging/customer support. However I ran into issues with this as well, but already opened another thread.

    - optionally disable some USB3 functions of ports when we would run into issues operating at high speed. USB3 is a nice to have right now, but not required.

    Another minor issue we found is that the hub consumes 'high' current when it has booted but isn't configured yet. It consumes ~170mA and after configuration this drops to normal current .. few mA

  • +1 in reply to Mark Beuvink
    TI__Guru 60870 points

    Ok, I was hoping we would be able to find options for you to not use the SMBUS interface at all, but if you are doing a polarity swap, there's no other way.

    Changing the descriptors will not show up at the top level in Device Manager if you use Windows, but you would be able to see them if you use usbview.exe or USB Device Tree Viewer.  The Device Manager values seem to be driven by the driver file matching to the VID/PID, not the descriptors.

    The SMBUS programming current is expected.  It got added to the hub datasheets later, but it looks like it didn't propagate to all versions.  I'll get that added on the next refresh.  This is from the TUSB8041 datasheet but it would apply here too:

  • 0 in reply to JMMN
    Prodigy 85 points

    Thanks!

    Current makes sense now.

    Also thanks for the VID/PID info. At this time I was still running into the problem that when programming the PID/VID string the hub didn't enumerate at all.. I think it has to do with not programming a string that windows accepts. But this has low prio for now. Good to now that it is not usefull for general device manager and thus not usefull for customer support anyhow.

    We will have to redesign the board.. if we cannot come to a good I2C configuration we can consider swapping the USB2 lines so the hub can run stand-alone.

  • 0 in reply to Mark Beuvink
    TI__Guru 60870 points

    Ok, USB 2.0 is pretty forgiving with routing.  Those USB tools I mentioned above are good for debugging descriptors.  If you continue to have issues you can send me the values you are using and I can verify them in our lab.