• State
  • Replies 5 replies
  • Subscribers 34 subscribers
  • Views 52 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

TUSB320: Failure in I2C detection

TUSB320: TUSB320 I2C Communication Issue

Vivek Sharma
Prodigy 10 points

Part Number: TUSB320

We have a TUSB320 in our system wired as shown below, and are unable to detect the device over I2C when running i2cdetect on our Linux host. We verified that the TUSB320 is powered, verified that the I2C request from our host is showing clean edges at 1V8, and can't seem to figure out why the IC won't respond? 

 image.png

  • 0
    TI__Guru 64746 points

    Hi,

    Is the host open drain? 

    Vivek Sharma said:
    We verified that the TUSB320 is powered,

    How was this confirmed. Do we see DRP toggling on the CC1 and C2 lines when the USB Type-C connector is disconnected?

    Are there other I2C devices on this bus. I see that the PUP for SDA and SCL is on the weaker side can we try an stronger PUP (2.2K?)

    Given that the ADDR pin is puled low the 7-bit I2C address should be 0x47 can you manually ping this. The i2cdetect command checks form 0x03 to 0x77 by default, has this command been modified at all?

  • 0
    Prodigy 10 points

    Hi Vishesh, 

    The host is an iMX93 SoM and the device tree is configured with the I2C ports in open drain mode, fast slew, etc. No other I2C devices on the bus. 

    I verified VDD was at 3V3, the enable pin (iMX93 output) is at 1V8, but I did not check the CC pins to see if it was toggling. I can confirm later today. 

    I did try i2cdetect in read mode (as to not use the Quick Write command) and also tried directly reading address 0x47, no response either way. 

    I could try increased pull-ups, but at 10k with no other devices on the bus the SDA and SCL edges look clean and levels are ~1.75V. The forum isn't letting me upload an image now, but I can upload a screenshot of the SDA/SCL capture once that works. 

  • 0 in reply to Vivek Sharma
    TI__Guru 64746 points

    Hi,

    Got it. Yeah if we see clean edges within the I2C timing spec for rise time, then the PUPs may not be the cause.

    I suspect that EN may not be set properly. The VCC for this pin is 3.3V, and the EN pin VIH and VIL is dependent on this.

    EN must be at or close to 3.3V for the part to properly enable. 

  • 0 in reply to Vishesh Pithadiya
    Prodigy 10 points

    Hi Vishesh, 

    The datasheet does list a separate spec for VIH_EN on the TUSB320HA as min 1.05V so I assumed the 1V8 logic on the enable should be OK? 

    Clock and data edges are fairly clean - see below (ignore the packet - this was a scan at 0x46, but I am aware the chip should be at 0x47)

  • 0 in reply to Vivek Sharma
    TI__Guru 64746 points

    Hi,

    Can you confirm that the rise time for SCL and SDA is 300ns or faster? I cant see the timescale on the scope capture.

    Vivek Sharma said:
    The datasheet does list a separate spec for VIH_EN on the TUSB320HA as min 1.05V so I assumed the 1V8 logic on the enable should be OK? 

    Fai point, in our testing with the EVM  we use a 3.3V supply for EN without issue. 

    In this case, the best way to confirm the TUSB320HAI is on is the toggling CC pins. This will show the part is functional.