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

TUSB4041I-Q1: Questionable additional current draw?

Julio Apps
Expert 3665 points
Part Number: TUSB4041I-Q1

We are using TUSB4041 in our design.  It is a 4-port hub with one hub connected to the PC, and three of the downstream ports each connected to one more hub.  Each of them are then connected to other USB endpoints.

We are getting some intermittent strange power-up operation.  Power cycling looks good: 1.1v before 3.3v, small delay until reset is released.

 When power is applied and everything is in a good state (PC is connected and all hubs are operational), if I apply a reset signal to any hub, that hub draws an extra 220 mA from the 1.1v rail.  Is this normal operation?  I would of course expect the current draw to go down when it is held in reset.  I couldn’t find anything in the datasheet referring to reset current.  The only note in the current-draw table is that the current shown was “after reset”.

  • 0
    TI__Guru 60865 points

    Hi Julio,

    Is the SMBUS mode enabled for the hubs?  That's the only case where I can see that kind of power draw for the USB 2.0 hubs unless they are back driving something else in the system.  The configuration of the hub is undefined in reset, since the pins or EEPROM are accessed after the reset completes, so we did not define a specific power profile for that mode.  If you want to keep a hub inactive and in a low power state, I would recommend driving USB_VBUS to the hub upstream port low rather than trying to hold it in reset.

    Regards,

    JMMN

  • 0 in reply to JMMN
    TI__Expert 3665 points

    We pulled it high and the +221 mA goes away completely.  The problem is that we need to be able to access the hub via SMBus, but we do not want to program it at power-up.  Is there any way to accomplish this?

  • 0 in reply to Julio Apps
    TI__Guru 60865 points

    Hello Julio,

    The hub is designed to be configured at the end of GRSTz, this is to prevent the hub configuration from changing after it has already reported its descriptors to the USB host controller.  There isn't a clean way to configure the hub later.  What is being accessed via SMBUS in this application?  

    REgards,

    JMMN

  • 0 in reply to JMMN
    TI__Expert 3665 points

    The customer wanted to modify the PID/VID after the fact.  Turns out the hardware architecture didn’t allow this to occur due to no software controlled reset of the hubs.

     

    We’ve now added reset control as well as SMBUSz control.  So now the devices can power up in I2C mode and work with no problems (default values), then they can switch to SMBus mode and reset the chips.  They would then boot up, waiting to be configured.  I think this is all good, except…

     

    By default the devices will boot up using the TI VID and the default PID.  Is this allowed in a product?  I would think not.

  • 0 in reply to Julio Apps
    TI__Guru 60865 points

    Hi Julio,

    Actually hubs are one of the USB products where it is ok to use the default TI VID/PID.   If the VID/PID is changed the host controller will see the hub as a never before connected device.  For example, the first time a user connects a hub with default VID/PID, the host may show a status window that it is loading the generic hub drivers.  If the hub is disconnected and reconnected and nothing is changed in its registers, that status window will not appear again.  If the hub is disconnected and the VID/PID is changed and reconnected, the status window about loading drivers will show up again.  Functionally, it is no issue but it would occur.

    Regards,

    JMMN

  • 0 in reply to JMMN
    TI__Expert 3665 points

    Thank you!