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: EEPROM Access

Part Number: TUSB4041I

Hey there, we are using the TUSB4041I in a design that requires us to use the EEPROM. Can you please provide the programming tool?

Best regards,

Sebastian.

  • Hi Sebastian,

    Please accept my friend request so that I may send you the software. Please update the thread once you have accepted the request. 

  • Hey Malik, I had accepted your friend request this morning but just now realized you asked me to update the thread afterwards... so here we go.

  • Hi Sebastian,

    The software has been sent. Please post here if you have any issue or questions. 

  • Hey Malik,

    Thanks again for sending the software.

    We still have issues with the TUSB4041I. The drivers and the programming software seem to work as far as we get, but then we seem to run into a hardware issue: The 1.1V rail fails. It is supplied by a LDO of type TLV73311PDBVT which has internal 300mA current limiting. Could it be that the TUSB4041I actually draws that much current (datasheet says that only in SMBUS programming mode it would get to 225 mA)?

    In the meantime as a workaround for the overall project: How do we access OTP functionality? Is there a programming tool as well?

    Best regards,

    Sebastian.

  • Hi Sebastian,

    I am assuming that t you are seeing a overcurrent condition causing the LDO to reduce the power output correct? This may be caused by the inrush current at power-up. Do you only see the condition at power-on? You may need to use a LDO with constant current limiting or with a higher Imax.

    Also the OTP functionality is a programming tool as well and can be provided over direct message. 

  • Hey Malik, thanks for the swift reply.

    The condition as we see it now sure looks like overcurrent being detected by the 1.1V rail LDO (steep cut off of the output voltage). Also even in a situation where we are not trying to use the external EEPROM (pull up resitors on SDA and SCL) removed we see a very high total current consumption (3.3V plus 1.1V rail) of up to 400 mA that eventually drops when a connection is made to the upstream usb host. We are just now modifying the setup to measure the current per rail (removing the LDOs and supplying it externally) to assess the situation better, so we will know more tomorrow after further investigation.

    In the meantime to not keep the software team waiting any longer, we would like to try the potential workaround with OTP. Could you please share the respective programming tool as well?

    Best regards, Sebastian.

  • Hi Sebastian,

    I have already sent the software over e2e.

  • Perfect. Thank you. I will get back to you as soon as we have more insights - hopefully tomorrow.

  • Sounds good, I will wait on your reply.

  • Hey Malik, We have new results:

    After powering the TUSB4041I from an external lab supply we were able to use the EEPROM tool to input the desired config and it works. So far so good, but in the original configuration it will not work. The IC seems to have increased current draw on the 1.1V rail in certain conditions.

    • with no EEPROM attached and both pull-up resistors on the serial interface unassembled we get an acceptable current consumption of
      • 30 mA on 1.1 V and  10 mA on 3.3V with upstream USB connection established, no downstream connections
      • 50 mA on 1.1 V and  30 mA on 3.3V with upstream USB connection established and one downstream connection established (non USB-powered device)
    • with EEPROM attached and both pull-up resistors on the serial interface assembled however:
      • 320 mA on 1.1 V and 70 mA on 3.3V

    This is only if the EEPROM is NOT configured. After a successful configuration of the EEPROM and restart of the board we again get the acceptable values as it would be without EEPROM. Clearing the EEPROM completely (only setting first byte unequal 55h will not do the trick) and restart will give us the fault condition again.

    Next problem: Even with the EEPROM configured there will be a short time (few milliseconds) on startup when we get an increased current consumption on 1.1V (enough to trip the 300 mA overcurrent protection of the TLV73311PDBVT LDO that we have in the design right now. Again switching over to external lab supply we can work around this, but we still see the current being above 300 mA for a few milliseconds (does not look like inrush current). So bottom line: as soon as we have the I2C interface of the TUSB4041I configured with pull-ups in order to use an external EEPROM, the device definitely needs more than 300 mA on start up and will not work with a 300 mA current limited LDO.

    The datasheet states that the SMBUS programming current will be 225 mA on 1.1V. However we are well above that current and we don´t even have the device configured to SMBUS mode, but rather it is set for EEPROM mode. Also we don´t just see this problem while we put the device into the programming mode through switching the drivers and starting the EEPROM tool, but also at startup. I would not expect this behavior from reading the datasheet. Now I realize that the datasheet does not state "maximum" current, but it also does not seem to represent what is actually going on. Nonetheless it would probably be nice to update the info in there to actually make it understood that one needs.

    Also I sent you a private message about the OTP tool...

    Best regards,

    Sebastian.

  • Hi Sebastian,

    Have you seen this issue on multiple parts? Also does the 1.1V rail feed another components? Do you have and wave-forms form your testing that you can share?

  • Hey Malik,

    We have built 4 prototype boards with the design and we can see the same behavior on all of them. The 1.1V rail only supplies the TUS4041I. I have attached the relevant part of the schematic:

    I have also attached some waveforms from the power rails (yellow is 1.1V, green is 3.3V) in the case where we see the issue (EEPROM and I2C-pullups assembled, but EEPROM memory cleared. What you can see during power up is a step-wise ramp up (no clue where this comes from) on the first image. Then with a little more capture time (second image) you see that approximately 2.5s after power up the 1.1V starts to drop out and come back up periodically. The third image shows details on this (rather short ramp times let us guess that this actually the TLV73311PDBVT going into overcurrent protection (>300 mA) as indicated by our previous tests as well. We do realize that after the first drop in 1.1V the next ramp up is a violation of the power up sequence for the TUSB4041I, but obviously this is not the real underlying issue. Also interesting: Repeating the procedure will not always yield the same results: Though the problem always occurs, the timing of the on-off cycles in the 1.1V rail varies, more specifically the time the rail is "up" before the overcurrent condition occurs is fixed for one experiment (steady repetition) but will be different for the next experiment (after switching off the supply and turning it back on).

    Other than the TUSB4041I draws too much current what do you make of this?

    Best regards,

    Sebastian

  • Hi Sebastian,

    This is very strange indeed. could you also capture what SCL, SDA and GRST are doing after power-up? The burst read of the EEPROM should occur after GRST is de-asserted, typically in the  ~1 us region. could you measure the voltage on SMBUSz as well to ensure that TUSB4041I is not entering SMBUS mode some how, do you have the ability to pull this pin high and see if issue persists?

    Note: US holiday on 11/28 & 11/29, responses will be delayed. 

  • Hi Malik,

    Attached you´ll find the requested traces. Best regards,

    Sebastian.

  • Hi Sebastian,

    It seems that the 3.3V "stepping" is causing the burst read to occur before the 3.3V stable. This may be causing your issue, have you tried supplying only 3.3V from external supply and see if the over-current condition occurs on 1.1V rail?

  • Hi Malik,
    I did the measurement.
  • So Markus did the measurement, but apparently something went wrong with his image upload in the posting. But he had shared them with me via our chat as well so I just took the liberty to upload them now:

  • Hey Malik, any new thoughts on this? We are in the middle of a hardware revision for the system this is going into and would love to resolve this issue as well.

    Sebastian

  • Hi Sesbastian,

    Sorry for the late reply. If 3.3V is powered via external supply is it possible to have a faster ramp time to 3.3V similar to 1.1V rail? The images show a small step in the 3.3V rail which I would like to eliminate completely.

  • Hi Malik,

    I did measure a new power up sequence. I connected the pcb to one of our customizable power supplies.

    As you see, the 3.3V rail (and the communication lines) ramps up to about 0.7V as soon as the 1.1V is up. At this point the 3.3V rail is not enabled. While this happens, the hardware consumes a lot of power. This is more than it is specified for the chip.

    When 3.3V rail is enabled, the RST line ramps up to and communication starts.

    By the way: The shown powerup behavioris not the same as it should be in our Hardware design.

    Do you have any suggestions what we can change in our hardware design to get rid of our original mentioned Problem.... We are runing out of time

    Best regards

    Markus

  • Hi Markus,

    Sorry for the late reply. What are you enabling in your design through the EEPROM? I have been unable to recreate the problem on my side. 

  • Hi Malik,

    also the EEPROM is fitted to the PCB it is completly empty (all addresses are 0xFF).

    Best regards

    Markus

  • Hi Markus,

    Have you tired programming the EEPROM with appropriate values to see if the issue still exists?

  • Hi Malik.

    Yes, I already did program the EEPROM and yes it seems to improve the Problem.

    But that does not really solve the problem because when I program the EEPROM initially I run into the faulty state. This only worked when I provided power externally. The faulty state seams to occur while the chip is in programming mode. 

    I've tried this with three different Chips on different PCBs, so it isn't a Problem of a single chip and it seems more like a systematic Problem of the chip.

    Is it possible that the power consumption of the chip is much higher in programming mode?

    Best regards

    Markus

  • Hi Markus,

    This could be the case when TUSB4041I is in programming mode.  

  • Hi Malik,

    Maybe Markus was not as precise in his formulation as he could have been: The question was not, whether the TUSB4041I is consuming more current in programming mode (e.g. compared to active mode), but rather it is like this: We are seeing a current draw that far exceeds the values the datasheet suggests. We get >330mA on the 1.1V rail when the highest rating in the datasheet is 225 mA (and that would be for SMBUS programming mode, which we are not even using). The next highest rating is 86 mA (active mode with 4 HS devices) - this led us to believe we would stay far below the 300 mA current limit of the LDO we chose for the 1.1V rail. Now the real question stays: Are we doing something wrong is the spec in the datasheet just a little misleading ( I realize the datasheet does not state a "maximum" current consumption)? If so, the solution would be as simple as swapping out the LDO for somehting that gives us more current (at least >350mA e.g.), but if we are actually doing something else wrong with the TUSB4041I we would like to correct that.

    Can you please advise on that? I have attached the schematic for your reference (seems like the first time I had uploaded it, something went wrong).

    Best regards, Sebastian.

    1351.schematic.pdf

  • hi Sebastian,

    I believe that replacing the current LDO with one of a higher current limit may be the best course of action. The schematic attached looks good. I do recommend using 4.7k for R5 and R8. 

  • Hey Malik,

    First off: We don´t see different behavior from changing the pull-up resistors values to 4.7k, but thanks for the advice.

    You marked your last reply as suggested to resolve the issue. The initial question of this thread has long been resolved by you kindly giving us access to the programming tool. I believe the issue we have been discussing the last few weeks is a completely different story and no, for me this one is not resolved. I suppose the problem will go away by redesigning with more current available, but we still have no clue whether this is expected behavior (thus the datasheet might be a little misleading) or we actually have a design flaw on our side. And yes, we will redesign to accommodate a higher current voltage regulator and see how that works out. From what we have seen we would hope that it does the trick, but honestly I am not exactly happy. Should there be some hidden fact about the current consumption of the TUSB4041i in all this it would probably be a good idea to actually reveal it and just put it in the datasheet. Of course one might still wonder why the IC would need all the current but in the end, as long as the design has enough power budget it can be dealt with.

    Obviously we will not know for sure before the redesign is on the bench and tested and as stated are not entirely satisfied with this, but for now it seems there is not much more we can get out of this discussion. So thank you for your support. Enjoy the Christmas holidays.

    Best regards,

    Sebastian.