• TI Thinks Resolved

TPS65987D: Slave Address ID is always 0x00

Intellectual 2515 points

Replies: 6

Views: 34

Part Number: TPS65987D

I have a customer using the TPS65987, BQ25703, and BQ4050 similar to the TIDA-01515 but with only 1 USB C port. They are having issues with I2C on the TPS65987. They can communicate to the BQ4050 with no issues but are having difficulties on the BQ25703.

From the customer:

I2C seems to be able to read and write to the TPS65987 correctly. I  can change parameters, write them and then read the changes back in debug mode. The one parameter I don't read back correct is the slave ID, always comes back as 0x00.

When I do the I2C address scan I see devices at both 0x22 (the TPS65978) and 0x6B (the BQ25703A). So the BQ25703A is responding

Thanks,
Nick

  • Some additional detail: 

    I was originally trying to use I2C1 to control the BQ25703 (on address 0x6B). I have also tried I2C3 just to be sure. Both resulted in me reading the value (which was sett to 0x6B) as 0x00 when I went into DEBUG mode.

    I only have I2C1 from the TPS65987D connected on my board. I am trying to use this for both controlling the BQ25703 and talking to the TPS65987D (in DEBUG mode) (and since SPI is not working, programming the TPS65987D, for now). It is also the same I2C bus being used to control the BQ4050, though I program that separately and am not expecting the TPS65987D to control that.

    Do you think reading the TPS65987D in DEBUG mode over the same I2C bus is creating a problem?

    Thanks,
    Nick

  • In reply to Nicholas Carley:

    Hi Nicholas,

    To make sure I understand, you are wanting to have the TPS65987D act as both the master and slave on I2C1? This will not work as you cannot have a device act as both a master and a slave. The master is responsible for driving the I2C clock and initiating the conversation so a slave cannot also serve in this role.

    If you want to control the TPS65987D, you will need to connect to I2C2. This should allow you to read the proper slave address for the device

    Regards,

    Adam McGaffin

  • In reply to Adam Mc Gaffin:

    Hi Adam, 

    I connected to the I2C2 port on the TPS65987D and was able to flash the RAM and enter DEBUG mode through the I2C2 port (leaving the I2C1 port free to be the master for the BQ25703A). This results in the same behavior as before though, I can flash the firmware and then read changes I make in DEBUG mode, but I always read 0x00 for the I2C master address.

    Best,
    Nick

  • In reply to Nicholas Carley:

    Hi Nick,

    Want to make sure I am understanding this correctly. You are wanting to read the address of the TPS65987D on I2C1 where it is acting as the master? You will not read anything back from the TPS65987D as it is the master and does not need an address following the I2C specification.

    Regards,

    Adam McGaffin

  • In reply to Adam Mc Gaffin:

    Hi Adam,

    The goal here is to read the slave addresses of the downstream devices connected to the TPS65987D. Below is the setup:

    1. External Aardvark/GUI communicating to the TPS65987D though I2C2 = TPS65987D acting as a slave
    2. TPS65987D communicating to BQ25703A and BQ4050 though I2C1 = TPS65987 acting as a Master to BQ25703A and BQ4050
    3. When we try to read the slave address of the BQ25703A or BQ4050 to an external PC or the GUI we get 0x00 rather than their actual I2C address.

    Nick

  • In reply to Nicholas Carley:

    Then this falls on both of those devices not advertising the proper I2C address. Make sure that they are powered and that the SCL and SDA lines are going to the proper pins for each respective part. You can also try disconnecting the TPS65987D so that the Aardvark you have connected to the I2C lines is the only master.

    Also make sure that the I2C channels are pulled up to 3.3V.

    This failure would not be due to the PD controller though but instead the BQ25703A and BQ4050

    Regards,

    Adam McGaffin