TPS65988DK: Can't access registers via I2C1 interface

Hi Adam,

When you say you can't access I2C registers, is the I2C address not acking at all?

Please ensure:

1. The PD controller is properly powered, VIN3V3 and LDO3V3 should be high.

2. You are connected to the correct I2C and it is configured correctly

If the I2C port is set as master in the config, it will not ack.

Also, does your end equipment need DP alt mode? What reasons are you currently looking at the TPS65987DDK.

Thanks and Regards,

Chris

Hi Chris,
Thank you for your reply.

1. About "When you say you can't access I2C registers, is the I2C address not acking at all?"

[Adam] -- No, the I2C address (write & read operations) is ack-ed right. For example, as below, to read register 0x04, the ack-s for I2C address-write, register number and address-read are correct, but PD controller doesn't respond the right "Byte Count".

More details about I2C wave captures, please refer to attachment I2C1_debug.docx .

2.

About "1. The PD controller is properly powered, VIN3V3 and LDO3V3 should be high."

[Adam] -- Yes. We confirmed, the voltage is right. 

3.

Where can I find this option in "Application Custom Tool"? But about the "ACK", I think it's correct, please see above reply #1.

4. 

About "does your end equipment need DP alt mode? What reasons are you currently looking at the TPS65987DDK.".

[Adam] -- Yes, we need DP alt mode (It's DisplayPort mode).  The reason please refer to previous post "TPS65988DK: schematic review".

BR,

Adam

Hi Adam,

Adam Chen said:

1. About "When you say you can't access I2C registers, is the I2C address not acking at all?"

[Adam] -- No, the I2C address (write & read operations) is ack-ed right. For example, as below, to read register 0x04, the ack-s for I2C address-write, register number and address-read are correct, but PD controller doesn't respond the right "Byte Count".

I'm still a bit confused by the logs you captured.

In step 3, it is sweeping through all the addresses and acking on address 0x46? Which I2C line are you checking? The doc says I2C1, but you should only expect 0x20, 0x21, 0x22, or 0x23 on this port, never 0x46?

You mentioned that you are updating the config on the EEPROM and it appears to be working properly? Is this correct?

Are you able to negotiate PD contracts as source/sink?

Can you share your latest project so I can take a look?

Adam Chen said:

3.

Where can I find this option in "Application Custom Tool"? But about the "ACK", I think it's correct, please see above reply #1.

This setting is in the Global system config register. You can also search for certain fields using the search bar at the top of the registers tab which makes it a little easier to find some fields. It looks slightly different in different versions of the GUI, below is a screenshot of 987DK in the 6.1.4 GUI.

At this spot, I'm still not sure why I2C is not working. It seems like the IC is not responding at all even though you see it acking at 0x46 in the logs you shared. Here are some things to try after you check the pjt file.

If you haven't already, can you try populating the IRQ pullup resistors and see if that changes anything?

Can you share an analog trace of the I2C?

Could you also try using a lower I2C clock speed? I don't think it should be an issue but you are right on the edge of the max speed. (400kHz)

Thanks and Regards,

Chris

Hi Chris,

Firstly, we've found out the root cause of I2C problem. It's a hardware compatibility issue. We've solved now.

Secondly, about I2C address "0x46" problem, it's 8 bit address, 0x23 << 1 = 0x46. Sorry about that I didn't write it clearly.

Now, we encounter a new problem:

How to configure a GPIO pin (for example: GPIO13) to INPUT?

We tried below 4CC GPie command, but failure. Did I miss something?

0x09 0x01 0x0D

0x08 0x04 0x47 0x50 0x69 0x65

Here is log:

#Enable GPIO13 INPUT
# ./i2ctransfer -y $BUS w3@0x23 0x09 0x01 0x0D; ./i2ctransfer -y $BUS w6@0x23 0x08 0x04 0x47 0x50 0x69 0x65; ./i2ctransfer -y $BUS w1@0x23 0x08 r5; ./i2ctransfer -y $BUS w1@0x23 0x09 r5;
0x04 0x00 0x00 0x00 0x00
0x40 0x00 0x00 0x00 0x00

#Setup GPIO12, will set GPIO13 HIGH
#./i2ctransfer -y $BUS w3@0x23 0x09 0x01 0x0C; ./i2ctransfer -y $BUS w6@0x23 0x08 0x04 0x47 0x50 0x73 0x6C;  ./i2ctransfer -y $BUS w3@0x23 0x09 0x01 0x0C; ./i2ctransfer -y $BUS w6@0x23 0x08 0x04 0x47 0x50 0x73 0x68;

#Read GPIO status register 0x72
#./i2ctransfer -y $BUS w1@0x23 0x72 r9
0x08 0x65 0xd0 0x00 0x00 0x67 0xd0 0x03 0x00

#Setup GPIO12, will set GPIO13 LOW
#./i2ctransfer -y $BUS w3@0x23 0x09 0x01 0x0C; ./i2ctransfer -y $BUS w6@0x23 0x08 0x04 0x47 0x50 0x73 0x6C;  ./i2ctransfer -y $BUS w3@0x23 0x09 0x01 0x0C; ./i2ctransfer -y $BUS w6@0x23 0x08 0x04 0x47 0x50 0x73 0x68;

#Read GPIO status register 0x72
#./i2ctransfer -y $BUS w1@0x23 0x72 r9
0x08 0x65 0xd0 0x00 0x00 0x67 0xd0 0x03 0x00

BTW,

Beside GPie command, can we configure GPIO to INPUT from GUI?

The pjt file attached: 5305.tps65988dk_20250221_01.pjt

Thanks.

BR,

Adam

Hi Chris,

Just to make it clearer, my questions are:

1. How to configure GPIO13 to INPUT on GUI (if not, what about 4CC GPie command)?

2. How to read GPIO13 status (HIGH/LOW) via I2C bus? by 4CC command? and from which register?

Thanks,

BR,

Adam

Hi Adam,

Let me review the thread and I will get back to you early this week.

Thanks and Regards,

Chris

Hi Adam,

I went to test this on an EVM and ran into some issues. I'll need to check with and expert internally, please give me until the end of the week.

Thanks and Regards,

Chris

Hi Adam,

I checked with the team internally, and a general purpose input GPIO is not currently supported on the TPS65988DK. Apologies for the confusion and delays here.

The team is evaluating if we can add this functionality. If they get the go ahead, it may take a couple weeks to evaluate, build, test, and deploy the feature.

Thanks and Regards,

Chris