2024-10-21 11:26 PM
We are using the STUSB4700 in our PD implementation as a source. We have encountered an issue where it seems like the output is constantly switched on/off/on/off with about 500ms on, 200ms off timing.
Below is the schematic which connects to a USB type C connector and a SoM. Please note that we are aware that PD_1V2 should not be connected to the gates of the power FETs and we have patched this on the board we are testing with. Also, to make sure there is no interference from the SoM, the reset and alert line have been cut as well.
So to summarize the behaviour:
The input voltage seems stable for the most part with about a 1.4V drop when the fets are switched. Limiting inrush current eliminates the drop but doesn't eliminate the issue. The picture below shows the input in yellow and output in pink:
Please note that when we connect a NON PD device, the controller does output a stable 5V ~500mA. Once there is any communication everything fails.
We also have access to the I2C registers but didn't find anything useful through that.
Solved! Go to Solution.
2024-10-22 12:52 AM
Hello
So the behavior is correct: by default, STUSB4700 will advise 5-9-12-15-20V to USBPD sink.
If contract is done on 9V for example, stusb4700, thru is monitoring feature, will expect to see voltage increasing to 9V. If not, issue is detected and that's why vbus_en_src is released.
If you want to operate only at 5V, I suggest to use STUSB1700 which is 5V only.
To keep stusb4700, you need to change NVM: change number of PDOs from 5 to 2 (this is the min).
On PDOs I suggest to setup 5.1V for example (as it should not advise 2 times same voltage).
Best regards
Nathalie
2024-10-22 12:27 AM
Hello
Vs description you are providing, it seems that voltage does not raise as expected so that stusb4700 detects a monitoring issue which explains VBUS_EN_SRC going high.
I do not see in the schematic how PD_GPIOx nets are connected to power supply, in order to change the regulation point and output correct voltage, vs negotiation done and I suppose that there are PDOs above 5V
Can you please provide this part of schematic ?
Best regards
Nathalie
2024-10-22 12:34 AM
Hi Nathalie,
Makes sense, we might be missing something in that regard.
The PDOs are all left on default.
The GPIOx are all floating and connected to testpads. This is the full schematic:
We are not using the GPIO configuration as as of now we do not expect to be using voltages above 5V.
2024-10-22 12:52 AM
Hello
So the behavior is correct: by default, STUSB4700 will advise 5-9-12-15-20V to USBPD sink.
If contract is done on 9V for example, stusb4700, thru is monitoring feature, will expect to see voltage increasing to 9V. If not, issue is detected and that's why vbus_en_src is released.
If you want to operate only at 5V, I suggest to use STUSB1700 which is 5V only.
To keep stusb4700, you need to change NVM: change number of PDOs from 5 to 2 (this is the min).
On PDOs I suggest to setup 5.1V for example (as it should not advise 2 times same voltage).
Best regards
Nathalie
2024-10-22 02:27 AM
Hi,
Thank you, this fixed the issue. It makes sense, we just weren't fully aware of how the PDOs work. For any future reference, we wrote the following registers:
# Disable PDO3 (write 0x00 to 0x79-0x7C)
write 0x28 0x79 0x00
write 0x28 0x7A 0x00
write 0x28 0x7B 0x00
write 0x28 0x7C 0x00
# Disable PDO4 (write 0x00 to 0x7D-0x80)
write 0x28 0x7D 0x00
write 0x28 0x7E 0x00
write 0x28 0x7F 0x00
write 0x28 0x80 0x00
# Disable PDO5 (write 0x00 to 0x81-0x84)
write 0x28 0x81 0x00
write 0x28 0x82 0x00
write 0x28 0x83 0x00
write 0x28 0x84 0x00
# Set PDO2 to 5.1V (write 0x66 to 0x75-0x78)
write 0x28 0x75 0x66
write 0x28 0x76 0x66
write 0x28 0x77 0x66
write 0x28 0x78 0x66
2024-10-22 03:30 AM
Hello
To avoid further issues, I do suggest to change @x70 = xA3 to @x70=x43
In this case, only 2 PDOs will be sent as source_capabilities, during PD negotiation.
Setting PDOs to 0 while keeping PDO_nb to 5 won't prevent stusb4700 to send out 5 PDOs with not-allowed values: Sink might be disturbed and reset the connection...
Best regards
Nathalie