cancel
Showing results for 
Search instead for 
Did you mean: 

STUSB4500 drives I2C SDA low during power up/down

s_
Associate III

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?

3 REPLIES 3
NBALL
ST Employee

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_
Associate III

OK, thanks NBALL

DanielThiele
Associate

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.