TPS65988: Problems with order of plug into USB-C ports

Hi Eric,

Is this system bus powered? Are you only getting power from the type-C port, or is there internal system power. 

Also, how are you loading the binary image, is this SPI flash based?

It's interesting that you see the plug present, but VBUS Status is 0. If you measure VBUS directly on the wall adapter port, do you see anything? Do you have the capability to get a PD log of this port?

Could you share a block diagram or schematic of the system? How is power getting from PPHV of the sink port to PPHV of the source port?

Thanks and Regards,

Chris

Chris,

I've enclosed  a PD trace of the Port 2 failing case.

This system is entirely bus-powered.  There is no battery or any power source other than the two USB-C ports connected to the 65988.

Yes, we have an SPI flash memory in the circuit.

Block diagram enclosed.

EricPort2 C6-USBH iPad first.csv

C6-USBH drawing 4.pdf

Hi Eric,

How are the power paths supposed to be configured in your system? Your block diagram seems to indicate that the internal power paths are being used to sink, but the pjt you shared seems to only have PP4 has a sink path? Could you relabel the block diagram shared with the expected power paths. I would have expected something like this, but what you shared seems to share a different story.

The PD log is somewhat limited, but seems to be fine? I see the proper power negotiation messages and don't see any error or reset message in the log. Is VBUS not coming up at all after the PS_RDY is sent in row 9? The PSRDY usually indicates that a voltage has been applied by the source.

I'm a little surprised that there is not failure or disconnects happening if the PD controller is reporting a VBUSStatus of 0. During this negotiation on port 2, do you see VBUS change at all, or does it stay at 0-V?

Eric Welch1 said:

The problem is that a subsequent plugin of a charger into Port2 is largely ignored.

What do you mean by "ignored". What is the behavior you are expecting and what are you seeing?

Thanks and Regards,

Chris

Thanks Chris,

Your labels on my drawing are accurate.  The external switch that you labeled "3" is driven from the PP3 (PP_EXT1) output of the 65988.  This gets turned on to charge the iPad on Port 1.

Yes, the PD log seems ordinary and the parties have negotiated a 14v PDO, and we have measured 14.6v at VBUS2.  When connected the Port2 status register is:

14188: GPIO1 (Port2) = 1
14190: Port 2 PlugPresent 1 ConnState 6 PlugOrientation 1 PortRole Sink DataRole UFP
VbusStatus 0 USBHostPresent 0 ActingAsLegacy 0 BIST 0 HVWarning 0 LVWarning 0 Ack_Timeout 0

This is what I meant by "ignored". Apparently the internal SW2 isn't turned on.  I haven't checked the power status register.

We tried turning PP2 to Sink in the Global Configuration, but that seemed to create other problems.  If that is the proper setting for this circumstance, we will go back and try to debug that.

Eric

Hi Eric,

Couple comments, I think I'm getting a better idea of your design and potentially some of the challenges/issues.

1. The PD controller is a port negotiation and power path controller
   1. There may be some concerns about your architecture. Typically we expect the power paths to consist of:
      1. VBUS connection from type-C
      2. A power path/switch controlled by the PD controller
      3. System power
   2. In the case of a "power path", it would either be one of the internal power paths (PPHV1/PPHV2) or an external power path controlled by a gpio or gate driver from the PD controller. In this case the following associations are made between the hardware and GUI/FW power path names
      1. PPHV1 -> PP1
      2. PPHV2 -> PP2
      3. Port 1 External power path -> PP3
      4. Port 2 External power path -> PP4
   3. 
   4. The power paths must be configured properly in the project and in hardware for the solution to work properly
   5. For your specific "ignored" issue, this is likely the problem. You would need to configure PPHV2 to be "PP Switch as Sink..." for the PD controller to utilize that power path when the port is a sink.
   6. What is interesting here is that you do not have PP1 configured correctly either in this case, so I am confused if the IPAD is providing power to the path correctly. What is likely happening, and that you would need to confirm, is that the dead battery configuration may be enabling the power path in "dead battery mode" and then the system boots the actual configuration but maintains the current connection. This would happen for both ports.
   7. What dead battery setting are you using? (ADCIN1 divider)
   8. 
   9. The point being made in 1.a is that your "4' sink power path is somewhat unconventional. We would typically expect some form of power switch to be between the VBUS connector of the Charger USB-C port and the TPS55289.
   10. Something like below, where PP2 is a dedicated sink power path and the input of the 55289 is taken from the system side of the PP2 switch.
   11. The main concern here is if you go for compliance, there are some capacitance requirements for the VBUS pin in a fresh connection state. Typically DC-DC converters will require input bulk cap greater than the maximum value(10uF for sink ports), and the power path (PP2 SW) prevents the bulk cap from being exposed on the pin during this time.
   12. 

Just to confirm, what are your power role, power level, and data role requirements for each port?

What issues are you seeing when you enable the PP2 power path?

Thanks and Regards,

Chris

Hi Chris,

1. Our ADCIN1 divider is 0.34 (BP_ECWait_Internal)

2. Goals for Port 1 (iPad connection) are always UPF, either Source or Sink.  You are right that it is booting in dead battery mode that forces Port 1 to be a Sink when the iPad is plugged in first.  When a charger is plugged in, we want to be able to Swap Port 1 to Source.

3. Goals for Port 2 (charger) are UFP, Sink.  It alwtays works if the charger is plugged in first, probably. because of dead battery mode.  What doesn't work if plugging in the iPad first and then the charger.  We see the PD negotiation on port, but internal switch 2 is never turned on.

Our next step is to debug a configuration with PP2 set for Sink.

thanks

Hi Eric,

Sorry for the delays here, item 3 definitely appears to be a configuration issue. You will need to enable PP2 as sink if you want this to work as described.

What is likely happening, is when you are in dead battery, your dead battery config will by default enable the internal sink power path due the setting you chose, and it remains in the active contract when the app config is loaded.

This explains the working case. Even though your app config does not have the sink path enabled, it is enabled in the dead battery configuration before the PD controller load the configuration in patch mode. Once the configuration is loaded to the PD controller, the PD controller will keep the active contract unless the config makes it act differently.

If you have a SPI flash, the intial "internal power switch enabled by default" can be changed by changing the config to something like BP_NoWait.

Thanks and regards,

Chris

Thanks Chris.  While not perfect, configuring PP2 as Sink gets us much closer to what we want.  Now, with the iPad plugged into port1, and then plugging a charger into Port2, the charger is recognized and its power switch turned on.  The only strange thing is that about 300 ms later, Port 1 registers a disconnect followed by a reconnect.  In this subsequent reconnect, all of the devices are well behaved, the iPad joins as Sink and gets charged and all of the data traffic works.  I am trying to run down why this happens, but it is definitely before I would otherwise issue the PR_Swap on Port1 to change it to Sink.

Hi Eric,

I'm not sure why the Ipad port is disconnecting and reconnecting.

Does your EC do anything during this time? Is there any signal that gets asserted and affects the PD controller? The 300ms timing is interesting.

Is there a discrete diode on the PPHV1 path as shown in your diagram? If you measure the PPHV1 voltage, does it change at all when the charger is plugged into port 2? It could possible be RCP, but if there is a diode it should block the reverse current.

It may also be useful to set up some of the interrupts and read some status registers to see if some fault is occuring. I would recommend looking into the folowing

Interrupts:

• Error_PowerEventOccured
• PPswitchChanged
  • and check Power pathregister if asserted
• PowerStatusUpdate
  • and check power status register if asserted

Thanks and Regards,

Chris