Rock5 does not work on most PD power supplies

The headsers should be able to handel 3A per pin as far as I know, so for a single 2 wire connection it would be 5v3A. I know the GPIO has 4 points for power. I’m currently listening to 2 electrical engineers argue weather that means 2x 5v3A and 2 gnd or 3x 5v3A and 1 gnd. I’m going to find the pin-out diagram and show them later on

They seem to have come to a consensus one one part at least.
They both agree that as long as the voltage is 5v then the board should only draw the Amps that it needs and any modern day electronic shouldn’t allow itself to draw more power then the pins can handle.

Update:
We pulled an NVidia SBC we used for testing and it was powered through 4pins on a 40 pin GPIO using 2x 5v3A and 2x Gnd for a total of 5v6A(30w) of power. That looks like the theoretical limit the board can be powered over GPIO

The GPIO is acess past the onboard regulator and what you supply and how you supply it is down to you.
Prob (2x Vcc and 2x Gnd) for 2x 5v3A as it makes a circuit you need both (vcc & gnd) or its half. After a google dupont 2.54mm will take 3amp to my surprise but some others say 2.5 amp. Its prob the cheapo crimps we get on jumpers that are 1amp as sure I have seen 1amp somewhere and looking would expect something in that region.

If you know how much surface area is on one of those crimps then its cringe not crimp.

So yeah maybe 25-30 watt max decent connectors and cable but there is zero protection on GPIO power usually and with the Roc5b you do get a 2nd buck which is more than most.

This is what I am saying its just far easier to get a usb-c and safer but hey do whatever you wish.

Here is what adafruit say not me or your electricians

Today, I tried an Intel 8260 WiFi/BT combo M.2 card on my Rock 5B, with a known working USB-PD power supply (negotiates 20V, 1.5A). To my surprise, I suddenly had power issues. Checking the sensors command, it reported “0V, 0A”, and the actual measured VBUS was 5V. Removing the card - stable 20V again. Reinstalled - “0V 0A”.

Turns out, the I2C line connected to the E-key M.2 is the same one that runs to the USB-PD controller. This card happened to do something bad with the I2C bus (trying to talk on the same address, shorting the bus, injecting noise or a non-I2C signal into it, etc. - didn’t debug it any further).

Masked off the I2C pins with some tape. Card and PD now both work properly.

Moral of the story: if you get power issues after installing an M.2 device, or if you get “0V 0A”, check your I2C bus!

1 Like

If it’s possible to use DC power supply 12v/5A with usb type c male connector
3141909563_w640_h640_type-c-papa-male.webp (26.2 KB)
jast melting two wire?

I think I got the same power situation when I installed 2T WD NVMe SSD.

Yep guess so as G & V are likely the vbus and really all that one of those USB-C adaptors does.
+/- I guess is data bus and not the same.
Adaptors do this already for you and its on you to make sure its correct otherwise.

I’ve used a UGREEN 65w GaN UK charger with success, sometimes it fails to boot once or twice, then just starts working. PD trigger cable also works, as does my Lenovo laptop 65w USB-C charger.
The voltage seems to be 20v. All in all, so far it works for me, using both the official Debian image and Armbian.

Ok so from my psu, the power is a solid 12.1v according to my multimeter, it doesn’t vary. So the barrel connector must be limiting it to 5v somehow or the sensors output is wrong? I’m not sure what to check here.

Masked off the I2C pins (58-61) with some tape.
According to the https://dl.radxa.com/rock5/5b/docs/hw/radxa_rock5b_v13_sch.pdf ,
Page Name: 06.PCIE-PCIE2.0_Slot-Ekey

Using the latest BSP kernel the sensors output is 0.0V on my 12V + USB-C barrel. So that output could be incorrect. To convert 12v to 5v you need a step down converter which is much more expensive than a barrel.

1 Like

Probably isn’t a sensor as the PD just negotiates and your just getting the default pd negotiation level.
If you have a 12v dumb psu via a usb-c then the onboard buck is getting 12v.

I have forgot the i2c querry to get the PD info but expect mine prob says the same

1 Like

This command should calculate the actual input voltage:

awk '{print $1/172.5}' </sys/bus/iio/devices/iio:device0/in_voltage6_raw

Great thank you, measure the same as the multimeter

awk '{print $1/172.5}' </sys/bus/iio/devices/iio:device0/in_voltage6_raw
12.1681

That works with a dumb psu

sensors
tcpm_source_psy_4_0022-i2c-4-22
Adapter: rk3x-i2c
in0:           5.00 V  (min =  +5.00 V, max =  +5.00 V)
curr1:         1.50 A  (max =  +1.50 A)

Would seem to be the negotiated pd level and because there is nothing to negotiate I guess its stuck at the 1st level.

So at this point we have 2 issues, one being the bootloader and kernel behaviour at boot.

The other the fact that the board has no exclusive SMbus/I²C for PCIe and USB-PD which seems to be a actual design flaw.

The above isn’t showing PD i2c because PD isn’t being used, plug in a PD and it will show the negotiated pd.
On an arm board with no bios the sensors prob need declaring in the dtb like tcpm_source_psy_4_0022-i2c-4-22 wasn’t at 1st.

I am talking about the cases were people used M.2 devices and it broke the PD negotiation.

These are obviously related and at this point it is pretty safe to say it is down to the SMbus/I²C not working in those scenarios.

I mean, we already have proof in a case where a person masked the pins on the card and it started to work.

I tried that and rock 5b still bootloops no luck