pi400 5v rail control

[cleverca22]

ive heard that the pi400 cant be powered from the gpio header
ive also heard that the 5v rail is being shut off fully when you do a shutdown
and given how the fn+f10 can turn the power back on, the microcontroller dealing with the keyboard must still be powered, and involved in control of the 5v rail

i'm guessing that there is a mosfet between the main usb-c in, and the 5v rail for the rest of the device
and that the keyboard controller is on the unswitched side

could an engineer confirm and/or clarify things?
will schematics eventually be released, that would include such details?

[aBUGSworstnightmare]

maybe there is a simple diode in the 5V line to the GPIO ...

My Pi400 should arrive this morning; will for sure test if it can be powered via GPIO and report back

[PeterO]

maybe there is a simple diode in the 5V line to the GPIO ...

Which way round you you put the diode ?
PeterO

[aBUGSworstnightmare]

maybe there is a simple diode in the 5V line to the GPIO ...

Which way round you you put the diode ?
PeterO

I'm speaking of an internal component (just for having common understanding) --> i.e. a Shottky Diode

Powering the Pi400 via GPIO is not possible! Just made a test with my Pi400.

[PeterO]

catho

maybe there is a simple diode in the 5V line to the GPIO ...

Which way round you you put the diode ?
PeterO

I'm speaking of an internal component (just for having common understanding) --> i.e. a Shottky Diode

Internal or external make no difference. You can't use a diode because you need current to be able flow both ways :
Out when powering an external hat
In when powering via GPIO.

Powering the Pi400 via GPIO is not possible! Just made a test with my Pi400.

Ok so it's a moot point anyway.
PeterO

[aBUGSworstnightmare]

You can't use a diode because you need current to be able flow both ways :
Out when powering an external hat
In when powering via GPIO.

the diode (just my guess, tbc) will not allow a current to flow from external to internal (powering via GPIO) , but it will allow current to flow from internal to external (supplying HATs --> possible for sure)
will measure voltage on GPIO later today

Ok so it's a moot point anyway.
PeterO

Not moot - sad point!

[jamesh]

Why would you want to power it from the GPIO? Isn't just using a proper power supply so much easier? This is a desktop device, powering via GPIO sounds like a very odd thing to do.

[aBUGSworstnightmare]

Why would you want to power it from the GPIO? Isn't just using a proper power supply so much easier? This is a desktop device, powering via GPIO sounds like a very odd thing to do.

Might be simpler to just confirm it's not possible instead of asking why people intend to do 'odd' things. If we know it's not the 'intended use case' people will no longer try to 'misuse' GPIO.

'Odd things' - because many of us have their own add-ons.

and ... to me a PI400 is not a 'desktop device', it's just another version of a Raspberry Pi

[fanoush]

Why would you want to power it from the GPIO? Isn't just using a proper power supply so much easier?

This is easier way if you e.g. wanted to keep usb-c on Pi4 free and use it as usb host? Not sure if it actually works, just tried the harder way - splitted usb-c cable so both power and usb device goes into pi (and power directly into usb device).

[cleverca22]

Why would you want to power it from the GPIO? Isn't just using a proper power supply so much easier? This is a desktop device, powering via GPIO sounds like a very odd thing to do.

i was thinking about how you might make it more portable, by having an external battery bank that connects to the gpio header to power the pi, and also add in 3.5mm audio, and a battery level api (via i2c)
if i'm already using the gpio header, making the board stretch all the way over to the usb-c port, would make it rather over-sized, and require a usb-c connector that mounts the right way on the pcb

and i wanted to avoid having cables being ran, to keep the form factor slim

[Imperf3kt]

Why would you want to power it from the GPIO? Isn't just using a proper power supply so much easier? This is a desktop device, powering via GPIO sounds like a very odd thing to do.

Might be simpler to just confirm it's not possible instead of asking why people intend to do 'odd' things. If we know it's not the 'intended use case' people will no longer try to 'misuse' GPIO.

'Odd things' - because many of us have their own add-ons.

and ... to me a PI400 is not a 'desktop device', it's just another version of a Raspberry Pi

I believe it was already stated in the Pi400 thread, powering via GPIO is an unintended use case and for an undisclosed reason, not possible with the Pi400.

[hippy]

maybe there is a simple diode in the 5V line to the GPIO ...

It's possible but more likely IMO that the 5V on the GPIO header is via some sort of MOSFET. Thus voltage into GPIO can't get to the internal Pi circuitry until the MOSFET passes current, and that can't happen unless power is in via USB-C ...

Code: Select all

5V GPIO O------------.
                 /   |
            .---O O--'
            |       
5V USBC O---^------------>

One would have to short 5V GPIO to 5V USB-C to allow GPIO powering if that's how things are. That's pretty much the same trick as used for allowing back-powering via USB on other Pi boards.

If the above is the case one could have a slightly more complicated solution which would allow powering via GPIO and allow powering via USB-C with switched power to the GPIO ...

Code: Select all

5V GPIO O---.---|<|----------------.
            |                  /   |
            `---|>|---.   .---O O--'
                      |   |   
5V USBC O-------|>|---^---^------------>

I believe it was already confirmed in the Pi400 thread, powering via GPIO is an unintended use case and for an undisclosed reason, not possible with the Pi400.

I expect we'll eventually discover whether it's possible with a simple board mod or genuinely not possible.

[LTolledo]

I believe it was already stated in the Pi400 thread, powering via GPIO is an unintended use case and for an undisclosed reason, not possible with the Pi400.

well seeing this may have dampen some of my possible projects with the RPi400 (if I ever get one soon)...
as most of my possible projects supplies power to the RPi via GPIO header....

well.... if there's a will.... there's a way.....
more creativity may be warranted for this endeavor....

[jamesh]

OK, so powering via GPIO is not possible on the pi400 due to stuff in there to stop nasty back powering issues happening.

It's also possible that the latest Pi4 will not do it either, but need to check.

In other news, there was a question about the USB power (VBUS) being cut when power is turned off, and yes, VBUS is off in that circumstance.

[cleverca22]

well seeing this may have dampen some of my possible projects with the RPi400 (if I ever get one soon)...
as most of my possible projects supplies power to the RPi via GPIO header....

well.... if there's a will.... there's a way.....
more creativity may be warranted for this endeavor....

hence why i am asking for more details on why it doesnt work

[cleverca22]

OK, so powering via GPIO is not possible on the pi400 due to stuff in there to stop nasty back powering issues happening.

It's also possible that the latest Pi4 will not do it either, but need to check.

In other news, there was a question about the USB power (VBUS) being cut when power is turned off, and yes, VBUS is off in that circumstance.

so there is both a diode(s) on the gpio header? (i can see that helping with 3v3->5v shorts killing things)
and also
a mosfet to cut power to the usb outputs at shutdown?

what about usb backfeeding power? not taken into account?

[aBUGSworstnightmare]

Well ... honestly speaking I don't care how it's done! Powering via GPIO is not working --> powering via USB-C is the way to go.

As my Pi400 arrived today I simply added a short USB-C power cable (https://www.berrybase.de/en/raspberry-p ... pply?c=336) to the 5V supply rail of my LVDS4PI EVO (yes! I consider the 5V/3A as a suitable power supply!), connected the board via a GPIO expander cable to the Pi400 and now it's on it's way to be transformed into a portable 'Frankenstein' laptop.

my new Pi400

1.jpg (83.74 KiB) Viewed 2334 times

power is supplied via USB-C power cable. Sadly not possible via GPIO as the Pi400 is considered a 'desktop device' (hence no longer just an ordinary Raspberry Pi)

2.jpg (93.25 KiB) Viewed 2334 times

Next action is to assemble another board which has an angled GPIO connector, getting rid of the I/O expander then as this can be directly plugged.

[dickon]

It's also possible that the latest Pi4 will not do it either, but need to check.

Wouldn't that render the PoE HAT useless on such devices?

[aBUGSworstnightmare]

OK, so powering via GPIO is not possible on the pi400 due to stuff in there to stop nasty back powering issues happening.

It's also possible that the latest Pi4 will not do it either, but need to check.

In other news, there was a question about the USB power (VBUS) being cut when power is turned off, and yes, VBUS is off in that circumstance.

Thanks for this info, appreciated!
Well, so far all Pi4 which I have in hands work happy beeing supplied via GPIO; even under heavy load.

[trejan]

It's also possible that the latest Pi4 will not do it either, but need to check.

I assume it does still work on the latest revision Pi 4 as the PoE HAT wouldn't be compatible if it didn't.

[hippy]

Wouldn't that render the PoE HAT useless on such devices?

I assume it does still work on the latest revision Pi 4 as the PoE HAT wouldn't be compatible if it didn't.

I imagine there's some checking going on to see if there is a problem or not.

Unless there's a D'oh! coming I can't see it not working because that would indeed be problematic.

I have my Pi in cases which feed 5V to the GPIO header from an internal PSU and the boards are positioned such that feeding via a USB connector would be extremely difficult, perhaps impossible. Not had a problem so far and fingers crossed I won't with newer Pi.

[jamesh]

Sorry, I'd misunderstood something I was told - it's only the Pi400 that cannot be powered via the GPIO.

[LTolledo]

Sorry, I'd misunderstood something I was told - it's only the Pi400 that cannot be powered via the GPIO.

yeah I was surprised when I read your earlier post...
the RPi4Bs that I have, like this RPi4B-4GB desktop unit, are powered via GPIO headers....

if some circuitry (by design and implementation) are preventing powering via GPIO headers on the RPi400
then lets just take that into account when making our own custom modules to be attached to the RPi400 GPIO header...

or if (that is a big if) a v1.2 version of the RPi400 board be released in the not so distant future....
phasing out the power blocking circuitry from the GPIO header...
...but I wont hold my breath for it....

will just ponder on what can be done with the current conditions....

[cleverca22]

thats why i would like schematics (even partial ones would do), so i can better understand how its blocking gpio power
and how it could be bypassed

[hippy]

or if (that is a big if) a v1.2 version of the RPi400 board be released in the not so distant future....
phasing out the power blocking circuitry from the GPIO header...
...but I wont my breath for it....

If the purpose of this blocking is to prevent 5V from reaching an external board when the 400 is software powered-off with PSU still attached, to limit potential damage when someone removes a board while it's in that state, it seems unlikely to me they would remove that power blocking circuitry.

It may be possible to alter firmware somewhere so that, as with PMIC control on the 4B, the 400's 5V is either disconnected or not on software power off, but that would depend on how it's controlled, what's controlling it.

From the RPT's perspective I can understand "5V and 3V3 is not supplied to the GPIO header when the 400 is software powered off, and that's all you need to know", but it would be nice to have a circuit diagram of the power supply parts just to satisfy curiosity and facilitate potential scheming.