Pogo pins power clarification - reading schematics

[dsimic]

So far, I think the only two real problems I have with the design are 1) the lack of isolation between a power source on pogo pin #1 and the USB C port, and 2) the strange "sometimes regulated 5 V" output on pogo pin #5, which you apparently have to assume is a variable voltage anywhere between 3 V and 5 V.

I agree, no separation between the pogo pin #1 (DCIN) and the charger port is a real issue, but only when attaching an external battery.  The other issue, variable voltage on the pogo pin #5 (USB-5V) pretty much boils down to using a separate voltage regulator as part of any "pogo mod" device, which is bad but bearable.

Haha, sorry to add to the confusion there. In a later post I discovered that I originally had PIN1 and PIN5 backwards. So those measurements are still valid, but you have to swap the PIN1 and PIN5 labels in that quote.

Believe it or not, there _is_ battery voltage on pogo pin #5, not 0 V, even when the phone is powered down. I measured it before, and I just measured it again just now to double check.

No worries and thank you for re-checking the measurement.  Here's a corrected summary of the earlier quotation, which I'll use to verify my conclusions further down in the post:

1) Phone powered down: 0 V at the pogo pin #1 (DCIN) and 4.0 V at the pogo pin #5 (USB-5V)
2) Phone powered up, no charger connected: 0 V at the pogo pin #1 (DCIN) and 3.9 V at the pogo pin #5 (USB-5V)
3) Phone powered up, charged connected: 5.0 V at the pogo pin #1 (DCIN) and 4.8 V at the pogo pin #5 (USB-5V)

As a side note, one more case should be worth trying:

4) Phone powered up, USB flash drive connected to the USB Type-C port (to turn the phone into a current source)

In the first case, having 0 V at DCIN is as expected because there's no charger connected.  The same applies to 0 V in the second case.  Also, having 5 V at DCIN in the third case is as expected, because there's a charger connected.

Actually, DCIN can be 0 V, and PS can still be nonzero voltage. From the PMIC's point of view, it can select 3 sources for PS: ACIN1/ACIN2, VBUS, or the battery. On page 6, Q600 is a (bulky) transistor which connects the battery directly to PS (through R601 though). It's turned on when the PMIC selects the battery as the source via N_BATDRV.

If I'm not wrong, R601 should be the PMIC's 0R01 current-sensing resistor, and it acts as a PCB trace when it comes to connecting VBAT to PS through Q600, which is controlled by the PMIC as you've described. 

In the first case above, I still have some doubts about 4 V at USB-5V.  First, why is Q600 enabled by the PMIC while the phone is turned off?  Second, the battery is declared with 3.8 V as the nominal voltage, so why don't we see voltage lower than 3.8-4 V at USB-5V, which should be caused by the voitage drop across D600?

Pretty much the same question about the voltage drop caused by D600 applies to the second case above.  Whenever the LP6226 isn't enabled, USB-5V should show VBAT minus the voltage drop across D600, which clearly isn't the case.  Thus, something doesn't add up, meaning that further investigation is required.

So the answer is that, not to worry, pogo pin #1 _doesn't_ provide VBAT. And if a power supply is not connected to the USB C port nor to pogo pin #1 itself, then pogo pin #1 always reads 0 V like you expect. (Unless we enable the LPW5206! We haven't tried that yet.) But I'll answer the same question for pogo pin #5.

The path is from VBAT, through R601, through Q600, through L606, through D600, to USB-5V, which is pogo pin #5.

Even when the LP6226 is disabled, the connection through L606 and D600 can still carry current from PS right along through to USB-5V (maybe with a voltage drop across D600). This happens even when the phone is powered off.

The voltage drop across D600, which doesn't show up on USB-5V, is something that needs to be investigated further, if you agree.

Let "Vs" be the "supply voltage" output setting on the variable power supply. Let Vb be the "battery voltage" that you'd measure directly across the +/- terminals on the removed battery. Now, for Vb ~= 4.08 V, and Vs = 4.70 V, 4.80 V, 4.90 V, 5.00 V, 5.10 V, 5.20 V, or 5.30 V:

Phone off:

Code:

PIN5 = Vs - 0.20 V
PIN1 = Vs - 0.35 V

Hmm, something is either wrong there, or I'm missing something.  As we know, as soon as a charger is connected, the phone powers on, so it would be pretty much impossible to measure the effects of connecting a charger while the phone remains powered off.

I also noticed the "power loop", but I dismissed it. I think that any computer with USB OTG must have this same problem. You have a USB port which can act as the "device" side, where VBUS is supposed to be provided to you as an _input_ from a connected host. Or, your same USB port can act as the "host" side, where you are supposed to provide VBUS as an _output_ to a connected device.

I cannot remember where (maybe in the PineBook Pro schematic?), but I've seen power switches as part of the USB circuitry that are used to cut off the bus power when a power source (not a power sink) is connected to a OTG-capable USB port.  Those power switches were described by the component manufacturer as made specifically for use with OTG USB ports.

Of course, providing a power input that way should not happen when a charger is connected, as that would allow the power source from USB-5V to be fed to a charger; there's no isolation of power sources.

So I'll stand by my interpretation that we shouldn't provide power _to_ pogo pin #5 as an _input_ to the Pinephone.
Even so, yes, there is no isolation between pogo pin #1 and the USB C port's VBUS.

I really have nothing against that rule, but then what's the actual purpose of the LPW5206?  Unless there are actually different "USB-5V" power planes inside the PinePhone, instead of a single USB-5V plane, the schematic allows USB-5V to become a power source.  I know, it's strange and I don't see the actual purpose, but that's what the schematic shows to us.

As a note, any power provided to the phone through the pogo pin #5 would be limited to 500 mA or 1 A, depending on the type of LPW5206 used in the phone (there are two types of the LPW5206 IC).  That makes the whole design even more weird; why would anyone make the power input limit that low?

The 500 mA or 1 A limit must be for when the phone is acting as a USB host and is driving the USB C connector's VBUS; this limit makes sure that not more than 500 mA (or whatever) is drawn from the Pinephone as an _output_ through the USB C port.

That's exactly what I thought initially, because it makes perfect sense.  But, that would be the case only if the IN and OUT of the LPW5206 changed their places in the schematic.  With the IN becoming OUT and vice-versa, the LPW5206 would be taking DCIN and passing it to USB-5V, while limiting the current to 500 mA (or 1 A).  But, that's simply not the case currently, unfortunately.

Anway, I do think that the LPW5206's intended purpose is only for the Pinephone to provide 5V to the USB C port when it's acting as the USB host. Like you're saying, depending on the OTG state.

That would make perfect sense, but unfortunately that is not what the schematic tells us.

I think that if you ignore pogo pin #5, it's exactly what the schematics tell us. Just because pogo pin #5 is on the input side of the LPW5206, it doesn't mean that we _have_ to provide power there, or even that we _can_ or should. We definitely can draw power from there, though like we said before, we don't know exactly how much current is safe.

Could you, please, explain how did you come to that conclusion, based on the schematic?  I agree that it would be logical, but that is not what's in the schematic, unfortunately.

Also note that USB-5V definitely isn't _only_ controlled by the state of the USB port. I've already showed (by actually measuring) that if you only apply 5 V at DCIN, without touching any other USB pins (e.g. D+/-), the voltage of USB-5V will follow PS as it increases from battery voltage to 5 V. We also assume that you could otherwise enable the LP6226 (via the Allwinner A64's PD8 GPIO) to boost from PS from battery voltage to 5 V.

We should investigate that first, if you agree.  Your measurements are hard facts, but the schematic, as already described, provides a lot of conflicting information.

Sure, that would be a good experiment: Modify the kernel to allow direct control over PD8-VCC5V_EN, then compare measurements with that enabled vs disabled.

Maybe I can give that a try later. My approach would be to remove PD8 from the regulator node to make it available to userspace, then to just control it via the sysfs GPIO interface, e.g.,

Code:

$ echo 1 > /sys/class/gpio/gpioXX/value

That would be a very good test.

My guess is that the intention of the DCIN pogo pin is to connect an external battery.

I agree, but even more generally. The intention of the DCIN pogo pin #1 is to connect an arbitrary 5 V power source. Doesn't matter whether that's provided by a battery or a windmill. And depending on what the PMIC decides, that power source might be used to charge the Pinephone's internal battery, and/or to power all (or most) of the components on the mainboard.

Well, yes, but not easily if there is also a charger connected to the phone's Type-C port.  Let's remember, there's no isolation between the power sources inside the phone.  D'oh!

---

Edit: Recently announced February community update includes more details about the PinePhone keyboard case.  Here's a quotation:

Due to the battery’s size taking up the bulk of the space inside the keyboard’s bottom section, the charging circuitry had to be shrunk down to a tiny PCB. But don’t be deceived by it’s tiny size, this charging circuit can simultaneously charge the keyboard and the PinePhone via the keyboard’s USB-C port. Since I know someone will ask: the USB-C port on the keyboard can only be used charging, it doesn’t support data or any alternate modes.

Thus, the keyboard case, as already expected, will include built-in separate charger circuitry, but with a twist: it will charge both batteries.  Another twist is that the case will have a separate USB Type-C port, which looks like a workaround, IMHO.  Now, I'm wondering what will happen to the charging through the phone's USB Type-C port?  It will probably be incompatible with the keyboard case, so the phone's USB port will be used for data only, which can also be concluded from the following quotation:

This effectively completely frees up the USB-C port on the PinePhone. You can plug a convergence dock into it or use it for any other common USB-C devices, e.g. thumbdrives.

On second thought, having a dedicated power input through the keyboard case might actually be a good thing from the usability standpoint, but a phone with two attached USB cables will surely look a bit funny in 2021.