TPS25751: Some issue when used as Source

Hi Alex,

If possible, can you also provide PD logs of the behavior?

Can you also share the .json you are using to initially configure the TPS25751 with?

What Source Power levels are you using? (Voltage/current contracts expected)

Thanks and Regards,

Chris

Hi Chris,

Christopher Lim1 said:

If possible, can you also provide PD logs of the behavior?

How to export the PD logs? I did not find it in TPS25751's user manual and TRM.

Christopher Lim1 said:

Can you also share the .json you are using to initially configure the TPS25751 with?

USBCPD_config_V0.1_20240312.zip

OK, the .json is attached above.

Christopher Lim1 said:

What Source Power levels are you using? (Voltage/current contracts expected)

Does it mean the register 0x32 configuration? The following are used in the above .json:

Source PDO 1: 5V 3A

Source PDO 2: 9V 3A

Source PDO 3: 15V 3A

Source PDO 4: 20V 5A

Hi Alex,

How are you testing? Is this custom hardware or with the TPS25751EVM?

Alex Wang said:

How to export the PD logs? I did not find it in TPS25751's user manual and TRM.

PD logs are not generated by the TPS25751. USB-PD communicates using the Type-C CCx pins, and there are third party "PD analyzers" that can be used to log the messaging in a "PD log". The log will tell us which side is hard resetting and more information about the connection status.

Please try the attached json. I updated one of the register value that may have been causing an issue with different phones.

/cfs-file/__key/communityserver-discussions-components-files/196/6175.USBCPD_5F00_config_5F00_AW_5F00_V0.json

Thanks and Regards,

Chris

Hi Chris,

Christopher Lim1 said:

How are you testing? Is this custom hardware or with the TPS25751EVM?

We test with our custom hardware mentioned in the previous thread. We had a TPS25751EVM board on hand, but it could not start up normal, and we had not fixed this issue by now.

By the way, our custom hardware was normal when PD was used as Sink, when a 20V, 3.35A PD adapter was attached to Type-C.

Christopher Lim1 said:

PD logs are not generated by the TPS25751. USB-PD communicates using the Type-C CCx pins, and there are third party "PD analyzers" that can be used to log the messaging in a "PD log". The log will tell us which side is hard resetting and more information about the connection status.

Thanks for your detailed explanation. We used Kingst logic analyzer to capture the PD logs.

20240318_TPS25751_IssueDataCapture.zip

And I tried the attached json by the following steps:

(1)Open USBPD Application Customization Tool, and import the json you provided;

(2)Export and generate full flash binary in .c format;

(3)Update the binary data to our customer project and update EEPROM;

It seemed this issue was still not solved. The following is the related PD logs:

20240318_TIConfigure_TPS25751_IssueDataCapture.zip

Hi Alex,

Thanks for the information, give me a day to review and get back to you.

Thanks and Regards,

Chris

Hi Chris,

OK, thanks.

Hey Alex,

Sorry for the delays.

I've been having some difficulty using the Kingst tool. Is there a way to export the PD log ot a csv or test file to make it easier to decode?

Also, what are channels 3 and 5 connected to?

Thanks and Regards,

Chris

Hi Chris,

The language of Kingst files is changed, you could retry to open these files. The logs in .csv format are also output and attached.

The I2C's Kingst configuration is:

The PD's Kingst configuration is:

And you could see the decoded results:

Data of my configuration:

20240318_DataCapture.zip

Data of your configuration:

20240318_TIConfig_DataCapture.zip

Christopher Lim1 said:

Also, what are channels 3 and 5 connected to?

Channel 1: SDA of I2C between my MCU and PD's I2Ct_SDA

Channel 2: SCL of I2C between my MCU and PD's I2Ct_SCL

Channel 3: I2C INT of I2C between my MCU and PD's I2Ct_IRQ

Channel 4: USBC1_CC2

Channel 5: USBC1_CC1

Thanks and Regards,

Alex

Thanks for the information Alex, I'll review the PD logs.

Hi Alex,

Looking at the PD logs, could you obtain some additional information on the VBUS voltage and current at the time? We have seen similar behavior where the sink will draw too much power and the VBUS voltage droops due to overcurrent, resetting the PD contract and causing a constant restart behavior.

Thanks and Regards,

Chris

Hi Chris,

OK, give me a day to book the lab resource and capture the data.

BTW, could this issue be repeated by using mobile phones such as iPhone on your side? Is it a known issue for the development team of this TPS25751 chip? I know TPS25751 is in preview state,  and I want to know if TI had used TPS25751 as Source to test with different Sink devices such as mobile phones or not.

Thanks and Regards,

Alex

Hi Chris,

We used another mobile phone Google Pixel 4, still the same issue. Its VBUS voltage and current are as following:

And the related data with Kingst  logic analyzer is as following, notice the PD data seemed to change to display on Channel 5, which IS USBC1_CC1:

0407.20240327_GooglePixel4_DataCapture.zip

Thanks and Regards,

Alex

Hi Alex,

The spike in current draw does seem to be causing the droop in VBUS voltage, how much current is being drawn, the scale seems to be in volts.

Do you see this voltage droop on PP5V or VBUS?

Thanks and Regards,

Chris

Hi Chris,

It is 500mA one unit, you can see the following for reference, the peak current is around 600mA:

Christopher Lim1 said:

Do you see this voltage droop on PP5V or VBUS?

Do you mean the Green line in the pcitures? It seemed there's voltage droop on VBUS. Is it the cause for this issue? So how should we do to solve this issue?

Alex Wang said:

BTW, could this issue be repeated by using mobile phones such as iPhone on your side? Is it a known issue for the development team of this TPS25751 chip? I know TPS25751 is in preview state,  and I want to know if TI had used TPS25751 as Source to test with different Sink devices such as mobile phones or not.

Could you kindly respond to this post? Thanks.

Thanks and Regards,

Alex

Hi Alex,

Alex Wang said:

Do you mean the Green line in the pcitures? It seemed there's voltage droop on VBUS. Is it the cause for this issue? So how should we do to solve this issue?

Yes, this is likely the cause of the issue, If the VBUS voltage drops too low, the PD negotiation will stop and reset. Can you measure the PP5V voltage on the same scope capture and see if the voltage follows the VBUS voltage?

How much power is the DC-DC sourcing PP5V designed to handle?

We first need to determine why the VBUS voltage is dropping before we can solve the issue. It could be related to the 5-V DC-DC, or could be an issue with the power path.

Alex Wang said:

Alex Wang said:

BTW, could this issue be repeated by using mobile phones such as iPhone on your side? Is it a known issue for the development team of this TPS25751 chip? I know TPS25751 is in preview state,  and I want to know if TI had used TPS25751 as Source to test with different Sink devices such as mobile phones or not.

Unfortunately, we do not have a lot of USB-C test phones. I was able to find an S8, but it does not appear to have the same issue when used with the EVM. I have not been able to get an Iphone15 for testing either.

It is not a known issue, but I had a colleague who had seen a similar issue, we don't necessarily know they are the same though.

Thanks and Regards,

Chris

Hi Chris,

Christopher Lim1 said:

Can you measure the PP5V voltage on the same scope capture and see if the voltage follows the VBUS voltage?

OK, we will measure the related voltages and go back to you next week.

BTW, could you kindly help to check our circuit desgin? Thanks.

The PD is:

The DC-DC sourcing PP5V is provided by:

And the PPSYS is provided by the battery:

Thanks and Regards,

Alex

Hi Alex,

Due to the holiday, many device experts are currently out of the office. When they return they will look into this and provide a response. Please expect some delay accordingly.

Thanks,
Field

Hi Field & Chris,

OK, enjoy your holiday.

BTW, we found the cause of this issue. The PD chip what we used was TPS25751D, I did not notice "TPS25751D has a integrated bidirectional high voltage load switch for sinking power path: PPHV", and I thought VBUS could only be supplied by PP5V, as the following picture indicated:

Then for the charger BQ25751, it has the Reverse Mode, which could deliver power from the battery to the input(Here is PPHV for PD). So I enabled the Reverse Mode and found our system could charger the mobile phones such as Huawei Honor.

Thanks for your advice, Chis. Another two questions we want to be clear:

(1) For TPS25751D configured as Source, how does TPS25751D know which source(PP_5V or PPHV) to choose? i.e, in which scenarios this chip would use PPHV? And  in which scenarios this chip would use PP_5V instead?

(2) The chip needs some time to do its work when something happens, right? What's exactly the time? What we found in the debugging was that if the register Interrupt Clear for I2C1(0x18H) was directly cleared when I2Ct_IRQ was detected by our MCU, the chip would produced one or more interrupts on I2Ct_IRQ. That's why we used 500 ms delay in the question, and it was slow for our system.

Alex Wang said:

Hi,

To test TPS25751's Source Role, we used some mobile phone such as iPhone, Huawei Honor, and so on. It seemed TPS25751 could NOT be compatible with some of them, some issue happened. Could you kindly help to analyze?

In addition, the related TPS25751 registers' data was read as following,

(1)When I2C INT was detected by MCU, delay around 500ms;

(2)Read 0x03, 0x14, 0x1A, 0x3F, 0x40, 0x34, 0x35 Register;

Thanks and Regards,

Alex

Hi Alex,

Alex Wang said:

BTW, we found the cause of this issue. The PD chip what we used was TPS25751D, I did not notice "TPS25751D has a integrated bidirectional high voltage load switch for sinking power path: PPHV", and I thought VBUS could only be supplied by PP5V, as the following picture indicated:

Then for the charger BQ25751, it has the Reverse Mode, which could deliver power from the battery to the input(Here is PPHV for PD). So I enabled the Reverse Mode and found our system could charger the mobile phones such as Huawei Honor.

That's good to hear! I primarily support the USB-C PD parts, so I do recommend reaching out the the BQ team for BQ specific questions.

Alex Wang said:

(1) For TPS25751D configured as Source, how does TPS25751D know which source(PP_5V or PPHV) to choose? i.e, in which scenarios this chip would use PPHV? And  in which scenarios this chip would use PP_5V instead?

You will specify which path in the json/firmware. If you select Advanced Config, then go to "Source_PDO_1" in the "Transmit Source Capabilities" Register, you can select the Power Path for PDO1 as PP1(PP5V) or PP3(PPHV)

Alex Wang said:

(2) The chip needs some time to do its work when something happens, right? What's exactly the time? What we found in the debugging was that if the register Interrupt Clear for I2C1(0x18H) was directly cleared when I2Ct_IRQ was detected by our MCU, the chip would produced one or more interrupts on I2Ct_IRQ. That's why we used 500 ms delay in the question, and it was slow for our system.

Which interrupts were triggering and did you handle them, then clear them, or just clear without handling? I am not familiar with this delay issue.

Thanks and Regards,

Chris

Hi Chris,

Christopher Lim1 said:

If you select Advanced Config, then go to "Source_PDO_1" in the "Transmit Source Capabilities" Register, you can select the Power Path for PDO1 as PP1(PP5V) or PP3(PPHV)

Get it. So

(1)What's the advantages and disadvantages of PP5V and PPHV?

(2) The default values of other PDOs such as Source PDO 2 in the tool are configured as PP3, could they use PP1? i.e, could PP5V supply higher voltages such as 9V, 15V, and even 20V?

Christopher Lim1 said:

Which interrupts were triggering and did you handle them, then clear them, or just clear without handling? I am not familiar with this delay issue.

There's no specific interrupts we try to wait and handle for now. Our MCU just monitors the falling edge of  I2Ct_IRQ, and if there's, our MCU would read Reg0x14(Interrupt Event for I2C1) to check which interrupts were triggering, then read Reg0x1A(if there's Status Updated), Reg0x24(if there's Power Status Updated) and so on. And then we would clear the I2C INT by writing all 1 to 0x18.

Suppose there's no delay such as the 500ms mentioned above, we captured the I2C data via Kingst:

(1)1st falling edge on I2Ct_IRQ

Interrupt Event for I2C1 Register(0x14h): 3_Plug Insert or Removal, 24_Power Status Updated, 26_Status Updated is set to 1;

(2)2nd falling edge on I2Ct_IRQ

Interrupt Event for I2C1 Register(0x14h): 21_USB Host No Longer Present, 26_Status Updated is set to 1;

(3)3rd falling edge on I2Ct_IRQ

Interrupt Event for I2C1 Register(0x14h): 12_New Contract as Consumer, 24_Power Status Update, 26_Status Updated is set to 1;

That's why I think the chip needs some time to do its whole work when something happens. So which interrupt of  Interrupt Event for I2C1 Register(0x14h) should our MCU wait and then clear 0x18? 12_New Contract as Consumer and 13_New Contract as Provider seem not to be a good choise because they would not be triggered in some cases.

Or our MCU should delay some time to wait for TPS25751?

Thanks and Regards,

Alex

Hi Chris,

OK, got it. Thanks a lot for your detailed explanation.

And another basic question:

For the Int_Event Sink Transition Completed, could it be triggerred when some end device which does not support PD was attached to Type-C?

Thanks and Regards,

Alex

Hi Chris,

OK. BTW, I'll move to another task and continue to test TPS25751 on our custom hardware next week. I would continue using this thread to post TPS25751 related questions if you keep it open. Thanks a lot.

Thanks and Regards,

Alex