TPS65987D: Power is on and off at 18V and above

Hi Najee,

Based on the state logs you provided, it seems like the PD controller detected an under voltage condition, which causes it to reset. Can you provide a PD trace log instead? A good, affordable USB-PD adapter that we recommend is from total phase: https://www.totalphase.com/products/usb-power-delivery-analyzer/ 

Can you also double check if any of the schematic components have a max voltage rating of less than 18V? 

Regards,

Raymond Lin

Hi Raymond, thanks for taking a look. None of the schematic components look problematic as far as the max voltage of ~20V we hope to reach. The totalphase usb analyzer was out of stock, but we have the USB PD analyzer from cypress (https://www.infineon.com/cms/en/product/evaluation-boards/cy4500).

Here's a capture of a charging session that was abruptly ended on the above design (https://drive.google.com/file/d/16L5JorXqeEDNW_i5gdNowTCITL-KL6BN/view?usp=sharing or as a CSV: drive.google.com/.../view, and I'm attaching a capture of a charging session with the same sink (a usb-c laptop) against another design that works (https://drive.google.com/file/d/1VkVihXieOtNnuVL3zM8RIK9ufdV5v9tn/view?usp=sharing). And here's a ("good") session with the same sink against the TPS65987EVM (eval board for the TPS65987) that we also used for comparison: https://drive.google.com/file/d/14FKFMus1wjGS71O4gLqwbk0CWNcfb37T/view?usp=sharing

These can be opened using the CY4500 EZ-PD Analyzer Utility (free download from the infineon.com link above). In the case where were able to successfully hold a continuous charging session, we noticed that we lock in ~ 2.8A and are able to hold there. In the case where we get the spurious disconnects, it seems like we're getting to the same current, but get disconnected after a few milliseconds (see screenshots). This happens on repeat as automatic retries occur.

We are able to run the TI Application Tool in Debug mode if there are any TPS65987D register values you think might be interesting to monitor to better understand why the disconnect is being triggered

Hi Najee,

I'll take a look through the capture PD logs and see if I can identify any issues. In the Configuration Tool, can you take a look at the CC tab (0x69) and let me know what you see? 

Regards,

Raymond Lin

Hi Raymond, I don't seem to have that section. Here's what I have for Debug Registers:

Hi Najee,

When making a project, there should had been an option to select between Standard and Advanced. In the Advanced settings you can see more configuration settings that are not present in the Standard settings (such as the CC tab). 

Regards,

Raymond Lin

Hi Raymond, thanks for that. I took a video of the various settings, starting with the PD3.0 Status:

https://drive.google.com/file/d/11NPOIv5_ww9R7gpt1t4DEYigagfjtDkv/view?usp=sharing

and here's an exported PD data capture for that session:

https://drive.google.com/file/d/10_YRJ3uy5g82dEq6QIgS20uWVkNZr_r9/view?usp=sharing

I'm not sure what could be causing the USB connection to spontaneously drop. I have a cell phone that charges just fine @ 9V/3A. And this laptop that produced this session will get a good charging session if I limit the power supply to 18V, but allowing anything above that, I get these spontaneous disconnects.

I don't think there's a heat issue, since this happens readily and right away, and if I shift back down to 18V the re-connecting settles. All signs point to it being a component that is not happy with the higher voltage, but nothing seems to stick out, and we've tried to stay very close to the reference design, so pretty much scratching my head on this one.

Hi Najee,

Let me take a look through the drive and get back to you Thursday. 

Regards,

Raymond Lin

Thank you Raymond. And one other interesting data point that came in: if I remove PDO4 from the Transmit Source Capabilities, the device can charge fine (same cable, same sink, same everything), but limited to ~45W as expected. When PDO4 is added to the firmware, even if restricted to 16V, it probably gets requested and I get the spurious disconnects/re-connecting (seen in the video and logs). If PDO4 is added but restricted to 15V, then the Active Contract RDO Object Position stays at 3 (PDO3?) and I get a good charging session at 45W. I suppose the PD negotiation sees no need to go to 4 if 3 is offering the same power.

Hi Najee,

As you mentioned before, this worked with the EVM board? I haven't gotten the chance to read through the PD logs on Cypress yet due to download issues but looking through the CSV files, it seems the sink device is constantly trying to get sink capabilities from the source PD. Do you have any sink PDOs configured for the PD controller? 

Regards,

Raymond Lin 

Hi Raymond - yeah, I tried previously with the EVM board and it charges just fine from there. And I have Transmit Sink Capabilities > Number of Sink PDOs set to 0.
Should I try with Port Configuration > Type-C Supported Options set to "Try.Src", or Port Control > Power Swap strategy set to "Prefers Power Source"?

Global System Configuration > PP 2 Switch Config is already set to "PP Switch as Source Only (Output)" which I thought covers swaps

Hi Najee,

Try the Port Control -> Power Swap Strategy -> Prefers Power Source option and see what happens. By default if you had selected the "Prefer Power Source" option when making a new project this should already be enabled. Are there any PP# switch config set for sink?

Regards,

Raymond Lin

Thanks Raymond,

When I create a new project and choose TPS65987DDH > Standard > DFP, Port Control > Power Swap Strategy is set to "No Preference, Rejects All Swaps" by default.

I went with DFP because this is a battery (re)-charging application (source only/not a sink). Was it more appropriate to go with DRP with a preference for being a source?

When I manually picked DFP with "Prefer Power Source" there was no improvement.

I've got another interesting data point. I've been using a usb-c laptop as a sink, and with the laptop closed/sleeping, it'll pull ~ 2.5A-2.7A @ 20V, so we can properly switch and charge on PDO4, but the second I open the laptop, you can see a rise in current, likely from the laptop pulling more to power the screen or engage performance mode settings, and the charging is immediately cut:

And again, this is at 20V. I tried messing with these settings:

Namely, individually tried:

- Vconn supported -> DFP only, reject swaps

- Under voltage trip-point & UVP usage @ 50%

- OVP usage @ Disconnect if it exceed OVP Trip Point

- With UVP debounce turned on

No luck on any of those. I also tried to increase PDO4's current limit to 5A from 3A as our power supply can easily handle that, and I was looking to see is stepping over 3A was causing some over-current protection to kick in, but got a similar outcome:

I also captured some Debug Logs from the application customization tool:

 ti-logs-20220817.csv

There's mention in there of entering UVP state, but not sure if that's applying to the output, or if it's infact related.

Hi Najee,

DFP (Downward Facing Port) is not related to the power side at all, it's just stating how the data is flowing. For example, a Source device such as a monitor providing power to connected devices is also a UFP (Downward Facing Port) because it's taking in data from the connected device (i.e. laptop)

Najee McGreen said:

Was it more appropriate to go with DRP with a preference for being a source?

Try going with this preference and see the situation improves. 

My initial guess was over-current protection kicked in and was causing the current to drop but that may or not may be the case. I just got accessed to Cypress so I'll dig deeper into the PD logs and see if anything is out of the ordinary. If you have more updated PD logs please send them my way.

Thanks and regards,

Raymond Lin

Hi Raymond, sorry for the delay. I'm just returning to this. With DRP, and turning off sink PDOs, there was no improvement - I still get the disconnects. One additional data point is that with just the USB analyzer running (recording), I do see the CC lines flipping between some mV value and 0. Voltage and Current also cycle between 0 and some low value like 5mV and 2mA.

This doesn't happen on our working reference board - it will keep a consistent 2mA, probably owing to a little draw by the USB analyzer, so maybe this is a SMT/assembly issue at this point. I've been exploring getting more test boards made.

Hi Najee,

Let me check with the team to see if that's abnormal behavior for the CC lines. I'll provide an update latest this week!

Thanks and Regards,
Raymond Lin

Hi Raymond, just checking in: did the team have anything to say on this behavior of the CC lines?

Hi Najee,

Apologies for the delay response, according to my team that is normal behavior to have some small noise (in the mV range).

Thanks and Regards,
Raymond Lin

Hi Raymond, I got swept up in a few things and forgot to come back to this. Is there anything else we could try? Really kind of bewildered at how the chip is behaving

Hi Najee,

Can you provide the most up-to-date PJT file? 

Thanks and Regards,

Raymond Lin