TPS65987D: I2C control of TUSB1046 using TPS65987DDH

Hello Chris,

Thank you for your answer.

If you set up to Record Index 22 of I2C Controller Events according to the application note,

In App Config Binary Data Indices, set Port 1 I2C Record Start Index to 1 and I2C 1 Record Number of Indeces to 22 right?

We are trying to control the TUSB1046 by setting the TPS65987DDH registers with reference to the two application notes below, but it is not working.

How to Use TPS6598x I2C to Control TUSB564 in Monitor Design (ti.com)

TPS6598x DisplayPort Alternate Mode (Rev. B) (ti.com)

In particular, the HPD (GPIO3) of the TPS65987DDK does not transition to 'H'. Do we need to configure something else?

Regards,

MM

Hi MM,

Masashi Mineda said:

In App Config Binary Data Indices, set Port 1 I2C Record Start Index to 1 and I2C 1 Record Number of Indeces to 22 right?

Yes, this is correct.

If I understand correctly, the TUSB564 is a DP sink? It would be attached on a monitor.

If I remember correctly, the HPD signal for the PD controller on the DP sink side is an input, as the monitor/DP sink is the one that asserts the HPD in order to tell the DP Source that it is connected.

If you have a PD analyzer and can capture the PD logs, you would want to see DP alt mode negotiated and entered, and once you see the DP configure message, you should be able to assert the HPD on the DP sink and see an "Attention" message.

Can you share your pjt and I can take a look to see if anything obvious is missing?

Also, do you have a way of obtaining the PD logs mentioned above? It would be extremely useful in debugging the CC line communication.

Thanks and Regards,

Chris

Hello Chris,

I am grateful for your tremendous support.

We would like to control the TUSB1046(source) with I2C from the TPS65987, not the TUSB564(sink).

While I was searching E2E for a way to control the TUSB1046 via I2C, I found a thread introducing the TUSB564 application note and have been using it as reference.

We are trying to figure out how to configure the I2C for the TUSB1046 downstream rather than the TUSB564 upstream.

I compared the registers in the datasheets for the TUSB1046 and TUSB546, and I understand that the register configuration is nearly identical.

TPS6598x DisplayPort Alternate Mode (Rev. B) (ti.com)

In the above application note, the TUSB1046 is configured in GPIO mode, and the GPIO settings are very simple.

How to Use TPS6598x I2C to Control TUSB564 in Monitor Design (ti.com)

The above application note describes how to control TUSB564 using I2C instead of TUSB1046, but I feel that there are many setting items.

TPS65987D: How to connect to TUSB1046 through I2C instead of GPIO? - Power management forum - Power management - TI E2E support forums

The above thread states that if you configure the TUSB1046 according to the TUSB564 application notes, it will work, but I feel that this is not the case.

Regards,

MM

Hi MM,

Let me see if we have any updated app notes. You may need to reach out to the TUSB team separately to know what registers to write to. Our notes primarily give guidance on how to set up the I2C events and when they trigger, as you noticed, the actual I2C payloads may differ depending on the TUSB device used.

Thanks and Regards,

Chris

Hello Chris,

Attached is the project we are considering.

6431.TPS65987toTUB1046.pjt

(1) From the New Project of TPS65987DDH, I am creating a project with Advanced DFP only.

(2) Set I2C1 Enable as Master and change TBT Controller I2C Port I2C2 in "Grobal System Configration (0x27)"

(3) Set Slave 1 I2C Address to 0x0F in "I2C Master Configuration (0x64)"

Becouse I2C slave address of TUSB1046 is 0x0F.

ACK is returned from TUSB1046.

(4) "I2C Controller Events" and "DisplayPort Capabilities are the same as in the application note.

(5) Set Port 1 I2C Record Start Index to '1', Port 1 Record Number of Indices to '22'.

If we are missing any settings, please let us know.

Regards,

MM

Do you have any update?

We would like to know about the following three points.

(1) Could you please let us know if there are any problems with creating a project to control the attached TUSB1046 via I2C?

(2) When a connection is established by CC line negotiation, the HPD terminal (GPIO3) of the TPS65987DDH should transition to 'H', right?

(3) Could you provide us with a project that works with the TPS65987DDH and TUSB1046 EVM you have ?

    We would like to see the differences with our current project.

Regards,

MM

Hello Chris,

I have previously confirmed the I2C mode and GPIO mode of the TUSB1046 at E2E and understand that there is no difference in performance.

TUSB1046-DCI: Difference between GPIO mode and I2C mode - Power management forum - Power management - TI E2E support forums

/* Your mention */

The APP note defines a set of I2C trigger events that pertain to DP alt mode:

• Power On Reset
• Cable Attach CC_1 PD
• Cable Attach CC_2 PD
• DisplayPort Pin Config A,C or E CC_1 PD
• DisplayPort Pin Config A,C or E CC_2 PD
• DisplayPort Pin Config B,D or F CC_1 PD
• DisplayPort Pin Config B,D or F CC_2 PD
• DisplayPort Exited CC_1 PD
• DisplayPort Exited CC_2 PD
• Detach

Would it be okay to set Event "DisplayPort Pin Config A, C or E CC1_PD" and "DisplayPort Pin Config A, C or E CC2_PD"?

I checked with the team, and this event is supported by the TPS65987DDK. If not too late in the design cycle, we would recommend switching to the DDK version of the TPS65987. It should be the same hardware wise, and just requires that you build and generate the APP config FW using the DK option when using the GUI.

We would like to use the DDK, however we don't have time to change to the DDK and evaluate it.

Also, since it is not possible to modify the board to connect the TUSB1046 to GPIO mode, it must be operated in I2C mode.

When designing with DDH, are steps #21 and #22 unnecessary after performing the detach process described in the TUSB564 application note above?

For reference, we also tried setting the TUSB546 (not TUSB564) described in the application report below, but the TSP65987's HPD did not transition to 'H'.

Using I2C master in TPS65988 PD Controllers (ti.com)

Regards,

MM

Hi MM,

Masashi Mineda said:

Would it be okay to set Event "DisplayPort Pin Config A, C or E CC1_PD" and "DisplayPort Pin Config A, C or E CC2_PD"?

For events 21 and 22, they specifically configure the SBU -> Aux muxing. You will need to check with the TUSB1046 team to see if these can be set to a generic A,C or E event, or if setting those bits must be used with the Config E only. This is more on the DisplayPort side and I am not sure what is required. If they answer yes, you can combine this event with events 8 and 10.

The HPD signal should be asserted regardless of the I2C events assuming DP alt mode is negotiated properly and the attention message is sent.

Do you see an attention message being sent to the PD controller? Could you provide a PD log if possible?

How are you testing, are you connecting a monitor to the port? Do you see anything happen with the monitor? Can you read and share the Stats(0x1A) and Data Status (0x5F) registers when you expect to be in DP alt mode?

In your project, make sure the DisplayPort Capabilities Field(0x51) is set properly. Follow the DisplayPort Alternate Mode app note you linked above to set the register properly.

Please share your latest project. I noticed your initial project had almost nothing configured? everything appears to be set to 0. Which GUI are you using?

Thanks and Regards,

Chris

Hello Chris,

Thank you for your reply.

It would be too long to write it here, so I've attached the documents I compiled and the project.

/* TPS65987DDH project file */

TPS65987DHH_20241008b.pjt

/* Summary */

7522.USBtypeCPD_Alternate.pdf

We are currently testing a system with the TPS65987DDH connected to a real cable and monitor.

The monitor is simply supplied with 5V and displays a blue screen.

Regarding the PDOx settings, we connected it to Infineon's BCR CY4533 and confirmed that the voltage switches.

Therefore, I believe that I2C of TPS65987DDH and USB CC line negotiation is working.

We are using version 6.1.4 of the Application customization tool for the GUI.

Is it okay to read the data in the Stats (0x1A) and Data Status (0x5F) registers using the debug mode of the Application customization tool?

I have read and configured various TI's application reports, but please let us know if there is anything missing in the settings.

We are preparing to obtain a USB protocol analyzer.

Regards,

MM

Hello Chris,

Thank you for the verification.

I understood that the DP mode is being negotiated correctly in your environment.

We confirmed for the Stats register (0x1A) and Data Status register (0x5F) in debug mode, but the Data Status register (0x5F) was not found.

Could you tell us anything from the result of the Stats register (0x1A)?

We will get a PD protocol analyzer and take a look at it, probably next week.

Regards,

MM

Hi MM,

From what I see, it looks good, although I would need more info for DP.

• A device is connected (plug present)
• We are Source/DFP (expected for DP source)
• At least on Alt Mode entry successful
  • Potentially DP, but not 100% sure

Regarding 5F, in commands, there should be an option for a raw I2C read/write. Could you read from address 0x5F with a data length of 6 and share the raw data with me? We are specifically looking for the following bits:

• [8] DP connection
• [9] DPSourceSink
• [15] HPD Level

I think this information and the PD log will help us confirm why the HPD does not appear to be firing. I would also double check the connection of HPD on the schematic to make sure nothing is pulling it low externally.

Thanks and Regards,

Chris

Hello Chris,

We verified this with a protocol analyzer.

UsbProtocol.csv

The DP alternate mode negotiation communicated without any problems, and it can be seen that DP alternate mode was enabled by Attention.

However, even when we check the HPD pin of the TPS65987DDH by disconnecting it from other connections, the HPD pin does not transition to high.

After checking various things in debug mode, I discovered why the HPD terminal would not transition to High.

We think the problem is that the GPIO3 detection of the HPD pin is set to an input of 0x0.

We think that the HPD pin must output in DP_DFP, but could you please tell us how to change this setting?

We are using Application Customization Tool v6.1.4 (latest on TI website), is this issue happening anywhere else?

Regards,

MM

Hi MM,

Did you make any changes from the project you sharedt on the 10th. I would agree that that seems weird, but the pjt you shared on the 10th worked fine with the EVM I had. I don't think there is a way to configure the HPD GPIO, I will try to test on my end and check the same registers in debug mode next week.

I can't see the 2nd picture too well (for some reason I cannot zoom in on it), but it looks like our device is the DFP? 

Could you also report the Data Status register 0x5F?

Thanks and Regards,

Chris

Hi MM,

I tested once again with the 20241008b pjt and still see the DP alt mode and HPD working properly. Here is some of the status register information I see.

0x7 decodes to at least one alt mode entry successful.

I do see the EVM report the GPIO direction properly. Once again, I have not made any significant changes to the pjt provided. (only changes related to power and now to I2C1 Master setting so I can use an EVM and use Debug mode)

Can you read register 0x5f using the raw register read function?

Unfortunately, it does not report the HPD setting, as I see the GPIO asserted even though the bit is unasserted in the register, but it will still help us determine DP role information.

Can you confirm the firmware base image being used?

You can find this information in the General Settings tab.

Thanks and Regards,

Chris

Hello Chris,

When we checked the 5Fh register, the following result was as follows.

0x553 = 0000 0000 0101 0101 0011b

Bit 8 : DP connection is 1b, DisplayPort connection

Bit 9 : DPSourceSink is 0b, DP Source (DFP_D) connection

Bit 15 seems to be only Titan Ridge.

Firmware Base Image is the same as you.

I think the HPD terminal will be transition to 'H' in the environment that Chris evaluates, but the GPIO3 Data of GPIO Status Register (0x72) remains 0x0, right?

As additional information, my customer informed me that in their environment, changing GPIO3 to Output in debug mode outputs 'H' to HPD.

There's one thing I found out.

The customer's board is set to DFP only, but initially PP_HV1 was set to FLOAT.

Partway through the evaluation, they made a modification by connecting the PP_HV1 pin to GND with a wire, and are continuing the evaluation.

I similarly opened J4 of my TPS65987EVM and checked it, and even when connected to a display, GPIO 3 Direction did not transition to 0x1 and remained as an input of 0x0.

Even when I changed J4 on the TPS65987EVM back to the SYS_PWR setting and checked again, GPIO 3 Direction no longer transitioned to 0x1.

I think the problem is probably that PP_HV1 was FLOAT, but is there any way to restore the TPS65987 device?

The customer confirmed that since HPD on GPIO 3 did not work, he was able to use SSMX_DP on GPIO 0 as HPD instead of HPD and DP mode worked.

Regards,

MM

Hi MM,

Masashi Mineda said:

When we checked the 5Fh register, the following result was as follows.

Got it, yeah, that looks correct. I agree, the HPD bitfields in this register seem only for a tbt mode.

Masashi Mineda said:

I think the HPD terminal will be transition to 'H' in the environment that Chris evaluates, but the GPIO3 Data of GPIO Status Register (0x72) remains 0x0, right?

Correct, I see the correct direction, but I do not see the "GPIO3 Data" change to 1 even when I see the HPD output go high.

Masashi Mineda said:

The customer's board is set to DFP only, but initially PP_HV1 was set to FLOAT.

Partway through the evaluation, they made a modification by connecting the PP_HV1 pin to GND with a wire, and are continuing the evaluation.

I tested the EVM with PPHV1 grounded and floating and both seemed to work fine. Originally, I had J4 set to the SYS_PWR option but because the power path is disabled in the configuration, it shouldn't matter.

Masashi Mineda said:

I similarly opened J4 of my TPS65987EVM and checked it, and even when connected to a display, GPIO 3 Direction did not transition to 0x1 and remained as an input of 0x0.

On my 987EVM, I have J4 removed and tied PPHV to ground, and J5 is set between PPHV2 and VAR_DC. The monitor I have only requests the 5-V PDO, so it is fine, but if your display is requesting a higher voltage, you may want to remove all the other PDOs and only leave the 5-V PDO so as the higher voltage power source will fail on the evm due to differences in config.

If I load the project to the 6.1.4 GUI and flash the evm without making any changes, I see the HPD working properly on connection to display.

To actually use it in debug mode, you need to disable this bit as the EVM expects I2C1 to be an I2Cs port.

After programming with the exact project, I first power the board through the barrel jack. Then I connect the display. Directly measuring the HPD output on the Expansion Board Connector, I see 3.3-V on the pin.

2nd pin from right in back row

Here is the exact full flash binary I am using with the EVM, you can use the Binary->Flash from binary with this file. This is generated from the "...20241008b.pjt" without any changes, but providing in case there is some difference in binary generation. (There does not seem to be any as you are using the same base image and GUI, but providing just in case).

Masashi Mineda said:

I think the problem is probably that PP_HV1 was FLOAT, but is there any way to restore the TPS65987 device?

I'm not sure if PPHV floating is too much of an issue and do not know if it damages the device. It is recommended that the unused PPHV1 is grounded though. If the part did get damaged, I don't know of a way to "restore" it. They might need to retest with a new device.

Is GPIO 3 broken? Has he tried mapping SSMX_DP to gpio 3?

Thanks and Regards,

Chris

Hello Chris,

By connecting the SSMX_DP signal on GPIO 0 to the HPD of the TUSB1046 and the HPD of the GPU, the customer was able to supply voltage to the display and the crosspoint switch responded correctly to display the image on the display.

The I2C settings of the TUSB1046 are set correctly, so I will close this thread.

I experienced that the PP_HV1 pin should not be floated.

Apparently my TPS65987EVM broke when I ran it with J4 of PP_HV1 open.

Thank you for your tremendous support.

Regards,

MM

Hi MM,

If the customer is ok with that solution, then that should be fine. The timings for the SSMX_DP and HPD signals are different though, so it may cause issues if an attention message is not set but their system assumes HPD is high.

I'm not sure why their HPD is not working but everything I have tested on my end seems to point that their pjt is fine.

Thanks and Regards,

Chris

Hello Chris,

Thank you for your advice.

We understand that the timing of HPD and SSMX_DP is slightly different, and this is a temporary fix to check operation only.

It is also difficult to replace the TPS65987 device.

I would ask the customer to try this on a different board without ever floating PP_HV1.

Regards,

MM

Hi MM,

Understood, it may also be worthwhile to try swapping the IC on the EVM or ordering a new one if they are using it as a test vehicle.

Thanks and Regards,

Chris

Hello Chris,

Finally, Please let us confirm one thing.

When you checked the operation with the TPS65987EVM, what settings did you use for the DIP switches?

I think If PP_HV1 is connected to GND, DIP SW "4 ON ONLY" cannot be used.

Did you check the operation using the "4, 5, 6 OFF" setting?

Regards,

MM

Hello Chris,

Your support has deepened my understanding of TPS65987.

Thank you.

Reagards,

MM

Hi MM,

Closing this thread now. If you have a question related to the contents of the thread, feel free to reopen it by responding here, otherwise you can make a new thread.

Thanks and Regards,

Chris