Skip to main content
PRitt.1
Associate II
January 27, 2026
Solved

POWER_ONLY_ABOVE_5V appears to be ignored

  • January 27, 2026
  • 3 replies
  • 597 views

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:

 

PRitt1_2-1769530580514.png

 

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).

 
 

PRitt1_4-1769530621692.png

 

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

Best answer by Didier HERROUIN

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.

3 replies

Didier HERROUIN
Technical Moderator
February 16, 2026

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.

 

 

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
PRitt.1
PRitt.1Author
Associate II
February 27, 2026

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
Didier HERROUINBest answer
Technical Moderator
March 2, 2026

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.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
PRitt.1
PRitt.1Author
Associate II
March 5, 2026

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
Technical Moderator
March 6, 2026

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. 

 

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Didier HERROUIN
Technical Moderator
March 6, 2026

..

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.