POWER_ONLY_ABOVE_5V appears to be ignored

[PRitt.1]

Hi all,

I am using the STUSB4500 to power a device with a large inrush current. I have configured the PDO's for 20V @5A which should be more than sufficient to meet the power requirements.  I have selected POWER_ONLY_ABOVE_5V so that it will not attempt to power the device at 5V (which would draw 4 times as much current). See my settings below:

However, when I connect a 100W USB-C PD adapter to the circuit I see the chip first negotiate 5V before switching to 20V. I think that is expected but what I did not expect is the VBUS_EN_SNK to pass through the 5V. I believe this is causing the overcurrent protection to trip on the USB adapter (after a short delay) so we see the power turn off shortly after the switch to 20V. In the below scope trace the yellow is VBUS and the cyan trace is VSink (see  schematic attached).

Has anyone run into this issue?  Any idea what I might be doing wrong?

Let me know if I can provide any more details.

Best regards,
Phil

[Didier HERROUIN]

Dear PRitt.1,

I assume that for your tests, there is nothing connected on Vsink. Indeed, this phenomenon can be seen when Vsink is floating : by connecting a load, this state should be highly reduced.

Concerning the 20V output, I am not sure it is due to the Sink. Indeed, we can see that Vsink rises normally to 20V, which means that negotiation between the Source and the Sink is successful.

Above 3A, only smart cables can be used. Do you use a smart cable which support 5A and which is able to answer to the Source requests ? 

Do you have a way to look at the communication messages between the Source and the Sink using a USB spy like STM32G071B-DISCO ? It seems that VBUS collapse is decided by the Source, as VBUS also decreases slowly (and at the end, this is maybe the STUSB4500 which triggers the detachment when Vbus < 16V).

Note that instead of programming PDO2 and PDO3 with the same values, it is safer to set the number of PDOs to 2.

[PRitt.1]

Thanks @Didier HERROUIN 

It turned out that my FET was blown so it was passing VBUS to VSink regardless of what the VBUS_EN_SNK level was.

[Didier HERROUIN · Accepted solution]

The current through the transistor must have been very high, as the stl9p3llh6 can support up to 6A continuous. Let me know if you have other questions concerning STUSB4500.

Regards.

[PRitt.1]

Thanks @Didier HERROUIN .

I have run into another problem on one of my boards where VBUS_EN_SNK goes high/floating after about 10 to 30 seconds, turning off the output FET. There is no change in load or anything external changing that should trigger this. The VBUS voltage is steady and the POK remains on. I did find that there is a 1usec glitch on VBUS_VS_DISCH that coincides with the FET turning off.  Other boards with the same circuit I have tested are not showing this issue.

Can you suggest what might cause this or how it can be prevented?

Best regards,
Phil

[Didier HERROUIN]

Dear PRitt.1,

As it occurs only on 1 board, we could suspect an assembly issue. 
VBUS_VS_DISCH is an input, it is not supposed to generate any glitch.

To prevent VBUS path opening due to a glitch (on VBUS input), we recommend placing a filter on the VBUS_VS_DISCH input. This filter is present in our reference design, see attached. Indeed, VBUS_VS_DISCH is also used to monitor VBUS : if a glitch occurs on VBUS, with no filter, the chipset may decide to open the VBUS path. 

[PRitt.1]

Thanks Didier,

Can you point me to the reference design this is from?  The ref design I have has only a 1K resistor on the pin https://www.st.com/resource/en/schematic_pack/stref-scs001v1_schematic.pdf

In any case, I don't think the glitch is coming from VBUS because I 'scoped it on both sides of the 1K and it only appeared on the side connected to the VBUS_VS_Disch pin.

Best regards,
Phil

[Didier HERROUIN]

Dear PRitt.1,

The reference design is this one : https://www.st.com/en/evaluation-tools/steval-isc005v1.html#cad-resources

But I agree with you, it is unlikely the glitch comes from VBUS.

If you have the possibility to check the soldering or to change the component, it could confirm it comes from an assembly issue.