Skip to main content
s__it
Associate III
October 11, 2022
Question

STUSB4500 drives I2C SDA low during power up/down

  • October 11, 2022
  • 3 replies
  • 1294 views

I'm finding that t STUSB4500 drives its I2C SDA line low (for around 1 second) during power up or power down (the device is powered from Vbus only).

This prevents all communication with other devices on the I2C bus during this time.

Holding STUSB in its reset state does not help.

Any ideas how I could prevent the I2C bus getting blocked?

    This topic has been closed for replies.

    3 replies

    NBALL
    ST Employee
    October 19, 2022

    Hello

    When STUSB4500 is bus powered, I2C needs to be dedicated.

    May be figure 8 of datasheet is not clear enough but it tries to show that I2C lines are low till NVM is not loaded (i.e stusb4500 has been supplied)

    Best regards

    s__it
    s__itAuthor
    Associate III
    October 19, 2022

    OK, thanks NBALL

    Visitor II
    November 17, 2023

    And then, after booting completed, i can observe a regular <low> pulse on SDA - app. every 500ms. This is a START condition in terms of I2C - initiated by STUSB4500. It seems like there is an I2C master active inside STUSB4500.

    It could be acceptable, if your own master is handling all the bus arbitration correctly. But the problem is, that STUSB4500 I2C master does not observe bus for being IDLE before issuing START condition. That means during an ongoing transaction of your own I2C master, the STUSB4500 pulls SDA low even if bus is allocated.

     

    Following trace shows the SDA pulses every 500ms. No other transaction is run on I2C bus (by my own master)

    SDA low pulses every app. 500ms. No I2C transactions on bus.SDA low pulses every app. 500ms. No I2C transactions on bus.

    Pulse length is typ. 1.6ms

     

     

    Following picture illustrates the corruption of ongoing transaction by pulling SDA low. We are reading EEP and expect every byte to be 0xFF. This is measured but not proven here.

    During the 2nd byte read, one can see the read result to be 0x00 for future bytes.
    trace4.png

     

    Because the transactions proceeds, read results are 0xFF again - after STUSB4500 I2C master is finished pulling SDA low. See following picture

    trace3.png

     

    To make things worse: After corrupted NVM writing caused by above description. The frequency of SDA pulses low changes - to e.g. 34ms.

     

    Is there a good explanation for regular SDA pulses (START condition)? And is there a way to switch off completely (e.g. by NVM setting).

     

    Thank you and best regards.