TPS25750: Failing to switch VBUS to > 5V

Hi Olav, 

Thank you for reaching out!

Could you please provide a scope capture of the following: 

• VSYS
• GATE_VBUS
• GATE_VSYS
• VBUS Current 

Best Regards, 

Aya Khedr 

Hi Aya

C1 = VSYS

C2 = GATE_VSYS

C3 = GATE_VBUS

C4 = PP5V

There is no load on VBUS, except for the TPS25730 sink.

The 9V power supply measures <1mA

The 5V power supply measures a maximum current of approximately 5mA

I also want to add that if I connect the TPS25730EVM sink to a USB PD power supply (having the same settings as I am using when connecting to the TPS25750S) then VBUS is correctly set to 9V. I therefore conclude that the problems I have are related to the TPS25750S. 

The test setup has been running for a while, and the waveforms has changed. The waveform changes slightly between scans, as opposed to before. The high level of the GATE_VBUS signal is always stable and 4.5V, but the low level changes as can be seen from the picture. The high level of VBUS is also stable, but with different lo levels.

C4 is VBUS measured at TPS25730EVM. The other channels are the same as before.

If I measure VBUS on the TPS25750 , instead of the TPS25730EVM, I notice that the VBUS signal and the GATE_VBUS signals are identical. It seems like the charge pump is not active at all and that it simply acts as a switch passing the VBUS signal directly to GATE_VBUS

Hi Olav, 

Thank you for providing the waveforms, I will review and get back to you with feedback. 

Thanks Aya

In the data sheets I found the following figure for the GATE_VSYS driver, however there are no figure for the GATE_VBUS driver. Is the GATE_VBUS driver identical, except for GATE_VSYS replaced by GATE_VBUS and VSYS replaced by VBUS?

Hi Olav, 

I will check internally with our systems engineer and get back to you on Monday. 

Best Regards, 

Aya Khedr

Hi Aya

I just received USB-PD-CHG-EVM-01 evaluation board from TI. If I connect this board to the TPS25730EVM sink board, I get the same problem namely the TPS25730EVM being turned on and off due to missing 9V on VBUS. However this happens if I supply the USB-PD-CHG-EVM-01 from J1 (SYS). If I instead power USB-PD-CHG-EVM-01 from J2 (BATT) it works. Looking at the block diagrams I cant really understand why this makes any difference.

One thing I have not understood is how the TPS25750 knows the voltage on the PPHV input. If a 9V PDO has been negotiated, how does TPS25750 know if it actually have 9V on the PPHV input? Does it need some confirmation of this via the I2Cm interface, or the GPIO pins? 

The design we plan to make does not have a battery charger, and the PPHV input will always be 9V. Does the TPS25750  need some kind of confirmation about the voltage on the PPHV pin, before it opens the high voltage path?

Olav

Hi Olav, 

See below from USB-PD-CHG-EVM Design Guide: 

Apologies for the delay here, I will replicate with TPS25730 and TPS25750 EVMs on my end and get back to you by Thursday. 

Best Regards, 

Aya Khedr 

Hi Aye

I have finally got the MIKROE-5682 board to function as a source and to deliver 9V. 

What I did not understand, and what is not clear from the data sheets, is that it seems like the TPS25750 MUST be configured with a battery charger to function as a source if VBUS > 5V, even if you do not use a battery charger. The only clue to this is the configurator, where the only figures having  power directed into PPHV, is the ones having a battery charger.

I have one final question: Is it possible to perform patch download to TPS25750 not using a EEPROM but a MCU?

Hi Aya

Our design will not be battery powered and therefore do not need a battery charger, but we will need to source 9V on the VBUS. The design will have a MCU and we do not want to add a EEPROM if it can be avoided.

A simplified block diagram of the USB PD part of the design:

The prof of concept testing using the MIKROE-5682 PPHV has been performed by supplying 9V from an external power supply to the PPHV pin. 5V is supplied via the dedicated USB-C power input only connector. The I2Cs and I2Cm buses are connected to a Raspberry-pico working as a host on the I2Cs bus and a slave on the I2Cm bus. 3.3V are supplied from the Raspberry pico. As I told in my previous post it now works, but only after changing the configuration to a "Battery charger" configuration. This means that the TPS25750 is using the I2Cm bus for setting up the charger, but of cause there are no battery charger on this bus and therefore no ACK will be generated, but this seems to be ok.

We want to use the TPS25751 in our design, but the part is hard to get for the moment, anyway as you told the parts are pin compatible. Thanks for advising us to use the 51 in our new design, we will do that :-)

Best Regards

Olav

When do you need to use the "full flash binary" and when is the "low region binary" enough?

When the PP3 power switch is on (when sourcing 9V in this case) the controller reports PP3switch state as "reserved"

I am using the TPS25750S

I am pretty sure I have decoded correct, but just in case, her is the raw register values read from the controller. PPHV is measured to 9V:

HUB>usbpd r 0x26 l 5
Reg 0x26=0x2 (2,'')
Reg 0x27=0x20 (32,' ')
Reg 0x28=0x0 (0,'')
Reg 0x29=0x0 (0,'')
Reg 0x2A=0x40 (64,'@')

Why?

Hi Olav, 

1- The full flash binary is used when flashing the EEPROM. When writing the patch bundle from an MCU over I2C, it requires the low region only. 

2-  Register 0x26 is a 5 byte register. In the raw register values, I see other registers mentioned but it seems you are only reading 0x26. Could you please clarify the above? Do you have I2C logs?

Best Regards, 

Aya Khedr 

# Command for reading 5 bytes from register address 0x26
HUB>usbpd r 0x26 l 5

# First byte at address 0x26
Reg 0x26=0x2 (2,'')

# Second byte at register address 0x27. This is the byte containing the PP3switch field in byte bits 6..4. Its value is 0x2 meaning "reserved". I suspect this is a typo in the documentation. Looking at the 0x2 decodeing for the PP1 switch, 0x2 means switch enabled (system output), and this is what I expect for PP3 in this situation (sourcing 9V)
Reg 0x27=0x20 (32,' ')

# Byte 3 at reg address 0x28
Reg 0x28=0x0 (0,'')

# Byte 4 at reg address 0x29
Reg 0x29=0x0 (0,'')

# Byte 5 at reg address 0x2a
Reg 0x2A=0x40 (64,'@')

Do you agree that this is an error in the data sheet?

Best Regards

Olav

Hi Olav, 

It seems there may be a slight misunderstanding on the read register protocol (please see below from Technical Reference Manual).

As seen below, the first Byte read back will be the Byte Count of the register, so in that case you should be reading 6 bytes instead of 5. Also the 5 bytes are contained in one register and not into the adjacent registers (0x27, 0x28, 0x29, 0x2a). 

Could you try this and also send over the I2C traffic (decoded)?

Best Regards, 

Aya Khedr 

I am aware that the first byte read back are the nummer of byttes in the register.  The  5 bytes I listed abowe are bytes 1 to 5 of the 6 bytes read back. In other words all 6 bytes are 0x5, 0x2, 0x20, 0x0, 0x0, 0x40 but I only listed the last 5 as the first byte has no signifficance for the decoding.  Decoding all the bits in the 5 bytes are correct and make sense, except for PP3 decoding. I believe 0x2 for this bit is incorrectly listed as "reserved" in the manual. It shall be equal to 0x2 decoding for PP1. Note that PP3 has no listing for PP3 enabled as a system  output. This is missing an incorrectly listed as "reserved"