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.

TPS65987D: I2C2 addressing support

Part Number: TPS65987D
Other Parts Discussed in Thread: TPS65987

I'm having similar issues with TPS65987DDH and looking for support on this.

In my design I2C2 is wired to the microprocessors. On most boards the communication is happening over address 0x40 (0x20 << 1) which is I2C address for I2C1. ADCIN2 is pulled to ground thru 100K resistor so the three bits are 000 to get I2C1 address of 0x20.


There is one board where the address is 0x38 and I did not have to shift left by 1 here. I was expecting communication between microprocessor and PD on all boards over address 0x70 (0x38 << 1).

TBTController is set to b00 and I2C1 and I2C3 are not wired to any device and are pulled high thru a 4.7K resistor to LDO_3V3.

Thanks.

  • The only way that I can think this happening is if somehow I2C1 and I2C2 ports are shorted. 

    I2C1 can be addressed from 0x20 to 0x24 depending on the ADCIN setting.  I2C2 is 0x38 to 0x3F.

    Do you have an I2C trace or scope capture on the pins of your product?

    Regards,

    Chuck

  • I verified that there are no shorts between I2C1 and I2C2.

    I have 4.7K pull ups on all I2C lines. Datasheet says 10K, is this a must? And do they need to be pullup to LDO_3V3?

    Thanks!

  • Lalit,

    4.7K pullups will work just fine.  The 10K values is good for an I2C port with only 1 source attached that is close to the master device.  4.7K is a very good value for general use.

    The should be pulled up to LDO_3V3.  This prevents any possible power cycle issues when the TPS65987 boots up.

    Regards,

    Chuck

  • HI Chuck,

    Thanks for such quick replies.

    The I2C bus is shared with two sources. Both sources are slaves and micro-controller is I2C master.
    The pull ups are tied to a difference 3.3V source rather than LDO_3V3 and the designer tells me that its done this way to avoid race condition when configuring between two devices especially LDO_3V3 takes some time to come up.

    I went thru the datasheets but couldn't find any where documented how long LDO_3V3 takes to come up. Would you happen to have this information.

    Thanks.

  • Lalit,

    LDO_3V3 has a power mux between a LDO that only comes up when the type C connection is made and a 5V supply is present on the VBUS and a DIODE OR type circuit from VIN_3V3, so it is not totally constrained and it's power up will be determined by the system design.

    Your system does not appear to have a power supply ordering issue because it is able to communicate with the MCU, but is seeing the bus addressing incorrectly.

    Are you able to Scope the SCL<n>, SDA<n>, and VIN_3V3 (assuming externally powered) or LDO_3V3 (Assuming dead battery or Source only boot)

    If the supply is sold at 3.3V before the SCL/SDA pins are driven, then the system should work correctly, but if there is a sequencing difference, then we may have further issues to debug.

    Regards,

    Chuck

  • Chuck,

    I toggled HRESET line before configuring PD controller over I2C and this corrected the I2C address. Now all my boards are acknowledging on address 0x38 and not on 0x20. HRESET is wired to microprocess but was not used before and was pulled down to GND thru 100K resistor.

    Lalit