TPS65987D: "slow charging" issue with device acting as power source to phone

I'd like to update a few facts:

PP1 is used as power path as a sink (from VBUS to PP1HV) 

PP2 is used as power path as a source (from PP2HV to VBUS)

After the power swap, I observed:

1. USB port is disconnected from the phone (which was acting as DFP and power source prior to the swap)

2. Status reg (addr 0x1A):

PortRole(bit 5) = 0 (port is disable/disconnected)

ConnState(bit 3:1 = "100" (No connection)

PlugPresent (bit 0 = 0) (No plug present)

3. Power Status reg (addr 0x3F):

PowerConnection (bit 0 = 0) (No connection)

4. PD Status reg (addr 0x40):

PresntRole (bit 6 = 0) (SINK)

It's possible that the reason the phone doesn't draw current is because the USB connection is lost during the swap (actually it's lost because of the register Port Config (addr 0x28) being re-programmed as DRP to replace UFP). Without this mode change, the swap would not be possible.

I'm wondering if there's a way to re-establish the USB connection from the PD controller side? If there is, that would potentially solve the problem. Can you please advise?

Thanks,

Hi, May I know whether you cleared Deadbattery flag prior to PR swap?

Thanks

Hi Prajith,

Yes. The following programming (by a MCU host via I2C) was done right after dead battery boot process with power source coming from the phone:

1. clear dead battery flag (write to to CMD1 reg with 4CC string 'DBfg') - and yes I did verify it was clear by reading register 0x2D afterward.

2. write to Tx Source Capabilities reg 0x32 with value: 

0x0190000000000000000000000000000006412c0004b12c86e0b12c0101912c000000550000FC02

(this may be not necessary as the device still acts as a sink in this mode, but it was set up to prepare in advance when it becomes a source later)

After an external power source was applied (via another USB-C receptacle with 5V), the following programming steps were done in order:

3. write to Port Config reg 0x28 with value: 0x0000000000000119 (key point is changing to DRP state machine)

4. write to Port Control reg 0x29 with value: 0x00290082 (InitSwaptoSource)

After step 3, the USB connection to phone is lost. After step 4, the power swap appears to take effect as the phone starts seeing signs of incoming charging as follows:

a) brief flashing screen and then charging icon show up

b) message prompts with "Device is slowly charging .... use the charger that comes with manufacturer is recommended"

In reality, the USB connection is lost and the phone draws very little current. We measured the total consumption at the input where the external charge was applied, the current is only 150 mA (including the board and the phone, if it draws anything at all).

We expected that, after the power swap, the phone would become a sink while still maintaining data host (DFP) whereas our board would becomes a source while retaining data role as UFP, just like before the swap.

Can you please help pinpoint what went wrong with my set-up?

Thanks,

I'm attaching here the Application Custom Tool project that I based on to program my board.

Appreciate your help very much.Project_DRP.pjt

Hello Daniel, 

Please try the sample project tested on 87DH EVM. Please modify the project in case you are using it on a custom board. 

Following are my test steps.

1) Connect Type C plug to 87DH EVM. EVM will power up in dead battery mode

2) Clear deadbattery flag using 4CC command DBfg.

3) PD controller will immediately initiate PR_swap and switch to Source mode.

Thanks

Prajith 87_DH_DRP.pjt

Hi,

The project you sent works fine with the EVM (there is an extra step between 2 & 3 needed to make the swap, i.e. using 4CC command 'SWSr').

Now I'd like to duplicate the exact configuration like in your project to apply to my board. Can you help to answer the following questions:

1. How can we configure the device as DRP upon power on without the need to re-write register 0x28 by host over I2C (i.e. changing from UFP to DRP)?          My board does not have Flash to store pre-defined configuration.

2. To write to a particular register, which sequence is the correct order of execution in time?

a. write  I2Cslaveaddr, reg addr, N, byte1, byte2, byte3, ...,byteN

OR

b. write  I2Cslaveaddr, reg addr, N, byteN, byteN-1, byteN-2, ...,byte1

3. To write 4CC command by host over I2C, which way is correct:

a. write to CMD1 reg (addr 0x08) with 4 bytes of 4CC cmd as data argument (i.e. write I2Cslaveaddr, 0x08, 4, byte1, byte2, byte3, byte4)

OR

b. write to DATA1 reg (addr 0x09) with 4CC cmd (i.e. write I2Cslaveaddr, 0x09, 4, byte1, byte2, byte3, byte4), then write to CMD1 reg with no data.

Hi,

1. Default ROM configuration doesn't support DRP mode. So, you will have to configure the device using EC. I understand that there is an EC in your system, may I know what is blocking you from using it for DRP config? Please share the use case. 

2. Sequence a is correct. 

3.  Sequence a is correct. 

Thanks

Prajith 

Hi Prajit,

There's nothing to prevent us from using EC to communicate to the TPS65987D via I2C channel. That was exactly what we are doing. However, as soon as we changed the chip configuration from UFP to DRP, the USB connection with the phone was lost. Our intention was simply to swap power source with the phone while still maintaining data roles between the phone and our device (phone being the host, our device being peripheral). But that's another story we are least concerned now. We are willing to accept the fact of losing connection to shift our focus to the charging issue for now.

The immediate issue we are facing now is we can't get the TPS65987D to source the power properly as it should. As soon as we issue "SWSr" command to the chip, we observed the power is indeed swapped, but here are the nuisances:

1. VBUS voltage level is ony 4.2 V going to the phone (while the input voltage feeding PP_HV2 is ~5.2V; PP2 switch is used to bridge PP_HV2 to VBUS output)

2. Current draw from phone is very low (around 150 mA - 200 mA)

Perhaps our programming procedure is not right. Can you point out what registers (as minimum) and associated values and what order of steps we should program to duplicate the behavior of the EVM?

So far, in addition to clearing the dead battery flag command, we have written to the following regs (TxSrcCap, Global Config, Port Config, Port Control) with the values (see attached pictures) prior to issuing 4CC command 'SWSr'.

Hi Daniel,

May I know the patch version and ADCIN1 resistor divider ratio?

If possible please share PD protocol trace log. 

Thanks

Prajith 

Prajith,

My ADCIN1 ratio is 0.24, SPI_MISO is 0.

I chose to load Configuration 2 upon power on (UFP, internal switch).

I didn't have any patch because I thought I could program from host EC over I2C. After the EC boots up, I program the device with I2C transactions as mentioned.

Please advise if my methodology was wrong.

Also, I currently don't have a PD analyzer to record any PD protocol trace log. I can share the page of schematics here where TPS65987D is used (R31 value is actually 316Kohm 1%, not 194Kohm as shown)8640.PD_schem.pdf

Daniel

Hi Daniel, 

PD controller requires FW patch for its operation and it will not support PR_swap (4cc command/ register modification) when booted from ROM. 

Please find application note https://www.ti.com/lit/an/slva972a/slva972a.pdf for downloading patch from EC. Once patch download is successful, You should be able to do Power role swap. 

Thanks

Prajith 

Hi Prajith,

Did you have a chance to read my post above? 

As I reflect your question about the patch version, I'm afraid that maybe my problem might stem from icorrect method of configuration. Maybe I should configure the device as DRP from the beginning instead of going straigth to the default Configuration 2 (UFP).

If so, I'd like to try to re-configure the device as BP_ECWait_Internal (ADCIN1=0.34, SPI_MISO=0), then perform the patch bundle by loading the patch bundle to match the configuration in the App Customization Tool.

However, my problem is I don't know how to convert the binary file to a string of hex bytes to be used in my C-based program using I2C write function.

The I2C write function requires the data portion (after slave address, register address, byte count) to be arranged in an array of bytes (in hex). Since the 'PTCd' (Patch Download) command requires 64 bytes as input data at a time, I'd imagine we shall send as many commands as it takes. However, given a binary file, how can I extract it into a series of 64-byte arrays to be used in my I2C write function?

If you know how to do this, I'd appreciate your help very much. Thank you.

Hi Daniel,

Did you have a chance to read my post above? 

>>> Yes, as I mentioned in my previous post the PD controller in default configuration (whether UFP/DRP) will not initiate power role swap. So, load patch using I2C interface and then try PR_Swap. 

I don't know how to convert the binary file to a string of hex bytes to be used in my C-based program using I2C write function

>>>Figure 3 in https://www.ti.com/lit/an/slva972a/slva972a.pdf shows steps to convert Low Region binary file to C-Array which you can use in EC. 

Since the 'PTCd' (Patch Download) command requires 64 bytes as input data at a time, I'd imagine we shall send as many commands as it takes. However, given a binary file, how can I extract it into a series of 64-byte arrays to be used in my I2C write function?

>>>Please check code snippet DownloadDataChunk() on how to send the binary file as chunks to PD controller. 

Thanks

Prajith 

Prajith,

Thank you for the valuable input. I'm sorry that for some reason I didn't see your response on Jan 6 until today. 

Will try to follow the app note to do the patching after boot.

Thanks,

Daniel

Hi Prajith,

I changed to the patch loading programming flow following the app note. Unfortunately, the behavior was the same.

The power swap appeared to occur as I observed the following symptoms:

1. The phone app showed the change from output current (-300 mA) to input current (200 mA), which is very little (the app name is Ampere)

2. The output voltage from our board to the phone (VBUS) is only 4.2 V (a change from input voltage of 5V from the phone)

3. The transition from 5V input voltage (from the phone) to 4.2 V (from the internal PP2 switch) is INTANSTANEOUS

Compared with the behavior from the EVM module:

1. The phone app shows 1100 mA a

2. The VBUS voltage is ~5V (also from internal switch PP2)

3. There was a gap of 384 ms of the transition from input voltage to output voltage (5V -> 0V (384 ms) -> 5V)

The 2 waveforms are attached.

It appears that in my case there is something strange that makes the power switch PP2 not behaving as it should. It's not the problem of a specific chip as I tried on all the boards and they behaved the same way.

Can you think any possibility that cause this behavior? Do I need a firmware patch on the chip possibly?

Hi,

Glad to hear that the issue has been resolved :)

Thanks

Prajith