TPS65981: Legacy usb protocol switching

Hello Jordan,

Can you clarify what you mean when you say "if USB protocol is not initiated"? And can you add more description to what is happening with legacy USB power? There is quite a bit of legacy USB power so you will need to be more specific. 

Thanks,

Emma

I can add some more detail here, we are working on the same project.

We have a high power system where we are specifying that our customer can only use approved USB PD power sources giving a minimum of 15W of power. 

Should the customer plug in a non USB PD power source such as a mobile phone charger or desktop PC, then the TPS65981 should not pass any power through to our system. We want to do this since these devices are typically low power and can say only deliver 5W which is too little for our system to run once fully operational and we do not want the system powering up and then overloading the power source which then turns off  and repeating once the load is removed. 

We are currently seeing that with a non USB PD source, we negotiate no PDO contracts from this USB power source, but the TPS65981 still passes power downstream to our electronics.  

Can this operation with no valid PDO contracts be locked out in register settings anywhere ?

Thanks

Hi Andy,

To confirm, your device is a sink? How have you confirmed that a contract has not been negotiated? What are your sink PDOs you system offers?

Regards,

Emma

Hi Emma,  

See attached image (below) showing that we have no active PDO contract. In addition the power source is simply a USB 2.0 (non PD) phone charger.

We have sink PDO's for

5V / 3A 

9V / 2.5A

15V / 1.5A

To check that the original query is understood,  is there a register setting or operation mode whereby, in the event of no valid PD contract negotiated, the external VBUS is not passed through the device (or in our case external FETs) into our system.

Thanks Andy

Hi Andy,

What is your "Auto Negotiate Sink Min Required Power" value? This bit is located in register 0x37, Autonegotiated Sink. 

Regards,

Emma

Hi there, 

please find 0x37 register values below:

Regards,
Jordan

Hi Jordan,

In the Transmit Sink Capabilities register, 0x33, what is your minimum operating current for your PDOs? Can you change the minimum to 3A for your 5V contract?

Regards,

Emma

Hi Emma, 

We have adjusted this register so 3A, see our power profiles below:

Hi Jordan, 

Please note that the internal power paths of the device can only handle 3A so if you plan to use the internal power paths, please adjust your maximum operating current to 3A. Once you have done this, retry your test and let me know the results. 

Regards,

Emma

Hi Emma, 

We are using external power paths and we aren't necessarily seeing an issue with the maximum power. 

The issue is that the chip still supplies power to VBus when the chip has not negotiated power delivery contracts. 

Many thanks,
Jordan

Hi Jordan,

Apologies, I misunderstood your issue. Can you upload your pjt file and I can take a look? I want to check your external switch settings to see if the external power paths are enabled correctly. Which power paths (3 or 4) are you using or is one a source and one a sink?

Regards,

Emma 

Hi Emma, 

Find attached our power profiles. 

Many thanks,
Jordan
All PDOs Final.pjt

Hi Emma,  not too sure what you mean power paths 3 and 4,  I've attached the relevant part of our circuit (removing sensitive info) 

The power path we are seeing is from the connector (J7) through the two FETS (Q12 and Q13).  

However , We have done some more investigation and spotted another issue.

The two gate drives of the two FETs should be at least 4.5V above the source when active.    We are seeing that X93 is only 2V above the source while X92 is 5V above the source.   This applies both when a successful PD contract has been negotiated and also when a non-PD source is used. (But remember that a non-PD should not pass any power through in our case.) 

D1987_2_USB_PD_ONLY.pdf

Hi Jordan,

Could you test your project on an EVM? It seems like we may have some hardware issues going on but I'd you to test your project file on an EVM in order to confirm that this is hardware related and not firmware related. 

Regards,

Emma

Hi Emma,

I have just uploaded on to the EVM and vbus still remains at 5V without a valid contract negotiated. If There's any more test for us to do our end let us know. 

please find project below.

Many thanks,
Jordan

2117.All PDOs Final.pjt

Hi, I added a second query about low gate drive to external FETS.  Since this is a hardware not firmware question, I've raised a second query

https://e2e.ti.com/support/interface/f/138/t/954509

Andy

Hi Atiq, 

We have disabled this and the issue remains. please find our project file attached.

Many thanks,
Jordan 4718.All PDOs Final.pjt

Hi,  In addition because we have no need for legacy or BC or QC charging we have not connected the D+/D- signals to the TPS65981 chip so it has no visbility of legacy modes.

Hi Andy,

I think this could be related to the external FETs. I saw your other thread, what were your findings with the external FETs? Can you replace them and see if the issue persists?

Regards,

Emma

Hi Emma,  we have proven the external FETS are not the issue.  The FETs have been replaced, and they work in an identical fashion as the TPS65981 evaluation module and do turn on fully as the current drawn increases.   We are happy that the FETs work adequately.

We need to accelerate our answers to this as we have to start programming boards with firmware in the next week. 

To re-state, we need the TPS65981 when connected to (and sinking from) a non PD compliant power supply (and thus no active PDO contracts) does not pass power through to our system.  i.e. the external FETs are held turned off.

Hi Andy,

Glad to hear the FETs are working! 

Unfortunately, the PD controller needs to negotiate a Type-C implicit contract before moving onto the PD negotiation. If you disable the Type-C implicit contract, you will also disable the Type-C PD negotiation as well. 

Regards,

Emma