TUSB322I: PD fast charging abnormality

Hi Yuxi,

Yuxi Liu(Tony) said:

According to the PD protocol standard, if the cable does not have an E-marker, the idle CC pin should be 5V or 3.3V. For example, this is the case when TUSB322 is connected to a mobile phone via the standard type-c. The above does not seem to comply, so why can it work normally?

Our CC controller does not support the PD protocol. A CC controller is a simpler device and the CC negotiation will differ from a PD controller. In the TUSB322I datasheet, you can see that the unused CC line is expected to drop to nearly 0V after attachment:

Yuxi Liu(Tony) said:

When we tested TUSB322IRWBR as DFP and external fast charging function, we found that when TUSB322 was set to 5/3A fast charging, the CC1 voltage was 1.67V using the POWER-Z tool to monitor, which met the 5V/3A judgment standard in the PD protocol, but the actual connection to the mobile phone could only reach 5V/0.5A

From your description, it sounds like the TUSB322 is working correctly and advertising the correct current mode. The actual power delivered over the type-C connection will come from your power source and connect through your VBUS switch, not through the TUSB322I. Are you certain the power supply and VBUS switch have the capability to provide 3A current?

It sounds like the current is being limited to 500mA somewhere in your power circuitry. If you are able to provide the schematic I can take a look as well.

Best,

Shane

Shane Hauser said:

Our CC controller does not support the PD protocol. A CC controller is a simpler device and the CC negotiation will differ from a PD controller. In the TUSB322I datasheet, you can see that the unused CC line is expected to drop to nearly 0V after attachment:

If like you mentioned, when the TUSB322 connects to the phone via standard type-c, the voltage of the CC2 that is not used is 5 V/3.3 V at this time, which is not normal. Please help me analyze the reason, thank you! .

Shane Hauser said:

From your description, it sounds like the TUSB322 is working correctly and advertising the correct current mode. The actual power delivered over the type-C connection will come from your power source and connect through your VBUS switch, not through the TUSB322I. Are you certain the power supply and VBUS switch have the capability to provide 3A current?

It sounds like the current is being limited to 500mA somewhere in your power circuitry. If you are able to provide the schematic I can take a look as well.

Verify that the power supply and VBUS are capable of providing 3A of current, and we did an on-board test with an electronic load of 5V at 3A. Why is there some current limited to 500mA, I prefer that the phone is negotiating 5V/0.5A with the TUSB322 at this time, so the phone turns the load to 500mA. 

Hi Yuxi,

Yuxi Liu(Tony) said:

when the TUSB322 connects to the phone via standard type-c, the voltage of the CC2 that is not used is 5 V/3.3 V at this time, which is not normal.

Are you certain the cable you are using does not have an e-marker or VCONN capabilities? When an active cable is attached, the TUSB322I will supply VCONN on the unused CC pin:

Is this measurement taken on the TUSB322I side of the type-C connection or on the mobile phone side of the connection? Its possible the mobile phone is driving this high if it is on the phone side.

Yuxi Liu(Tony) said:

Verify that the power supply and VBUS are capable of providing 3A of current, and we did an on-board test with an electronic load of 5V at 3A. Why is there some current limited to 500mA, I prefer that the phone is negotiating 5V/0.5A with the TUSB322 at this time, so the phone turns the load to 500mA. 

If you've done a successful 3A load test on the port then the power circuitry is working properly. Have you tested this phone with another 5V/3A source to see if it is an issue with the phone itself limiting current draw?

Best,

Shane

The cable customer use should be have e-marked because when the cable is plugged in with the charger (the other end of the cable does not connect to the phone), POWER-Z indicates that CC1 is 3.3V and CC2 is 0.33V (the E-marker is internal with a 1k pull down. And the charger internal pull up 10K, which is exactly 0.33V).

As explained, the CC1 voltage is 1.76V (5V/3A decision) when the charger is connected to the phone, and the CC2 voltage is 0.33V: When the TUSB322I is connected to the phone, CC1 is 1.67 V, CC2 is 3.22 V, which is correct. Thank you!

This measurement was measured on the TUSB322I side of the Type-C connection, please know.

Added note about our TUSB322 register configuration flow:

1.After power up is complete, read out the value of 0x0A;
2.Replace bit0 of z with 1 and write into x0A register;
3.Replace bit5:4 of z with 10, bit0 with 1, write into x0A register;
4.Replace bit5:4 of z with 10, bit0 with 0, write into x0A register; // to DFP-only
5.Read out the value of 0x08 register y;
6.Replace bit7:6 of y with 10 and write into 0x08 register. // set to 5 V/3 A.

Hi Yuxi,

It sounds like our TUSB322I is negotiating correctly, and the CC2 line is supplying VCONN to your E-marked cable at 3.22V. If the charger's CC2 line is 0.33V its likely that the charger does not support VCONN.

Yuxi Liu(Tony) said:

When the mobile phone's built-in fast charging charger was used to power the mobile phone, it was measured to reach 9V/1.5A.

I do not believe this is an issue with our device. Since your charger is reaching 9V/1.5A there is clearly PD negotiation happening between the charger and the mobile phone. PD negotiation will replace the default pullup/pulldown system that the TUSB322I uses and is not a 1:1 comparison.

It sounds like the mobile phone is limiting current draw to 0.5A until a Power delivery contract is negotiated, which is not supported by the TUSB322I. Can you try using another charger with a CC controller (not a PD controller) advertising 3A, to confirm whether this is the case? Alternatively, you can try placing your own pullups on the CC1/CC2 lines according to the USB-C spec for 3A and check whether the phone draws 3A on VBUS.

The register configuration you describe looks correct.

Best,

Shane

TUSB322 When using the CC pins to negotiate the operating current externally when acting as a DFP, the voltage on the CC pins are specified as follows. This voltage threshold standard is not the same as the PD contract standard, Do you think this is root cause? 

Hi TIer

It has been confirmed that the customer's charger does not support the 5V/3A output, but it does support the 5V/1.5A output. According to the logic, when we get 5V/1.5A through the control of the CC pin, the output is very unstable, after some time will become 5V/0.5A from 5V/1.5A, Can you help with the analysis?

Thank you very much. Cheers

Hi Yuxi,

Can you show a waveform capturing the unstable behavior? Is the VBUS unstable or is it the CC pin voltage?

Just to confirm, our TUSB322 is in the customer's charger and providing power to the phone correct?

Best,

Shane

I'm asking my customer to provide these images, maybe not captured yet. Are there some possible reasons to share? For example, I set output 1.5A when will it drop to 0.5A? 

The customer's testing process is as follows:
1. IIC Hardware Configuration CC controller supports up to 5V/3A
2. Hardware uses CC controller + type-c socket + POWER-Z + e-mark cable + Phone/Pad
3. Just started the negotiation is 5V/0.5A, to maintain stability. 

Why we can't get 5V/1.5A?

Hi Yuxi,

Yuxi Liu(Tony) said:

I set output 1.5A when will it drop to 0.5A? 

Once a current mode has been negotiated, it should not change until the connection is re-established (plug/unplug). It could be that your device is not pulling the full 1.5A. How are you determining that the Current mode is changing?

Yuxi Liu(Tony) said:

Why we can't get 5V/1.5A?

From our earlier conversation, the TUSB322I is advertising 3A current, however the attached phone/pad is not drawing the full current amount. Have you tried testing with a non-emark cable? I'm wondering whether the e-mark in your cable is affecting the CC negotiation between the charger and the phone/pad.

Best,

Shane