Pogo pins power clarification - reading schematics

[bokomaru]

@dsimic, you're asking exactly the right questions to fill in the gaps! Awesome

Buckle up for a long response :-)

Quite frankly, no assumptions should be made when it comes to the PinePhone schematic.

Ahaha.

I think the design mostly makes sense (even if we don't fully understand it ourselves yet), but the trouble is that the intended behavior of the pogo pins isn't documented. So unless Pine64 tells us, we pretty much have to figure it out ourselves.

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.

However, let me reiterate on some of your earlier measurements (the following quotation is from one of your earlier posts):

Some investigation with a multimeter:

With a powered down PinePhone, I get 0 V from PIN5 and 4.0 V (battery voltage, unloaded) from PIN1.

Power up the PinePhone with no charger in the USB C port. I get 0 V from PIN5 and 3.9 V (battery voltage, loaded, modem is off) from PIN1.

PinePhone still powered on, now I plug in a USB C charger. I get 5.0 V from PIN5 and 4.8 V from PIN1.

As I understand it, 4.8 V is the voltage of my external AC to DC power brick in the wall under whatever load. I don't _think_ that's the voltage at which the battery gets charged. I think the max allowed for charging a Li battery is around 4.2 or 4.3 V, and anyways, since this battery is almost full, it's probably in the constant-voltage phase of charging. Maybe I'll hook up to a variable power supply to investigate more.

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.

To me, it is expected that 0 V is observed on the pogo pin #5 (USB-5V) while the phone is powered down.  In that case, there's no DCIN so there's no voltage on the PMIC's PS output, and the LP6226 produces no output.

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.

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.

This is somewhat strange...  When the LP6266 is disabled (and the LPW5206 is also disabled, but may also be enabled), there should be no power supply going out of the pogo pin #5 (USB-5V).

On the other hand, how is it possible that the pogo pin #1 (DCIN) provides VBAT while the phone is powered down?  According to the phone schematic, the battery is connected to the PMIC, the LED flash, the modem and the WiFi, but not to any of the power patths to any of the pogo pins.  Perhaps we should try to figure that out first.

Again, I really have no clue where from the pogo pin #1 (DCIN) gets the battery voltage when the phone is powered up and no charger is connected.  We should investigate that, if you agree.

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.

When the phone is powered up and no charger is connected, there should be 5 V on the pogo pin #5 (USB-5V), unless the LP6266 is disabled through software.  As you've pointed out, the SoC GPIO line that controls the LP6226 is present in the DTS file in Ondrej's kernel source, so it must be used by something.  I cannot figure out what is the actual purpose of having it disabled, unless the purpose is to "emulate" the presence of the charger through the voltage present on the pogo pin #5 (USB-5V).

Sure, good question. I don't know either why you'd want to disable it, given that its output also has to travel through the LPW5206 before going to DCIN. In other words, it should be safe to enable the LP6226, leave the LPW5206 disabled, and apply power to DCIN.

With the phone powered up and a charger connected, it is expected to have 5 V on the pogo pin #5 (USB-5V) and around 5 V on the pogo pin #1 (DCIN).  The pogo pin #5 (USB-5V) gets stabilised 5 V from the LP6226, while the pogo pin #1 (DCIN) gets aronund 5 V from the charger (which is probably going to be slightly below 5 V).  However, the above-stated questions still remain.

Yes, you'll measure the charger's voltage on pogo pin #1. The voltage you'll measure on pogo pin #5 will depend on whether or not the LP6226 is enabled. If disabled (which it apparently was for my measurements), then you'll observe the same voltage on pogo pin #5 as on pogo pin #1, with a slight voltage drop. If enabled (which I did not try, so unconfirmed), then pogo pin #5 will get boosted to its own independent 5 V value, not dictated directly by the voltage at pogo pin #1.

Here are my measurements proving what I just said for the disabled case. Again, be careful to notice that PIN5 and PIN1 were swapped there, before I did connectivity tests to learn the actual physical arrangement of all the pogo pins.

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

Phone on:

Code:

PIN5 = Vs - 0.20 V
PIN1 = Vb

Example:

Code:

When Vs = 5.00 V,
PIN5 = 5.00 V - 0.20 V = 4.80 V

Also notice that for this particular test, when my phone was _on_, my PS was apparently at battery voltage. I don't know why the PMIC didn't select ACIN/VBUS in that case, but given that the PMIC selected the battery, these measurements are still totally explained.

I also did another test using USB "power bricks" that you plug into the wall. And there, we see the other case when the phone is powered on, and ACIN/VBUS gets selected.

Next, I tried with three different USB "brick" AC to DC supplies, including one that's a fancy wall outlet with a built-in USB port:

Code:

PIN5    PIN1

old ipod brick, labeled 500 mA
4.3 V   4.1 V     (phone on)
4.4 V   4.3 V     (phone off)

fancy wall outlet, unknown characteristics
4.8 V   4.7 V     (phone on)
4.9 V   4.7 V     (phone off)

newer generic brick labeled 1 A
5.0 V   4.8 V     (phone on)
5.1 V   4.9 V     (phone off)

Wrong!

I made a bad assumption that the columns would line up. So I had PIN1 and PIN5 mixed up.

The confirmed pinout is this:

Code:

PIN6 PIN2 PIN4
PIN1 PIN5 PIN3

Code:

INT  SDA    SCK
DCIN USB-5V GND

And above is where I corrected my mixup between PIN1 and PIN5 :-)

Interesting! Are you saying that when the LPW5206 is enabled, you could actually provide 5 V as a power input to the Pinephone at pogo pin #5? I'm definitely scared to try that without understanding better :-)

Exactly, although it is very strange.   When the LPW5206 is enabled, the pogo pin #5 (USB-5V) turns into a power input for the phone, or at least that's what we can see on page 13 of the phone schematic.  While the LPW5206 is enabled, the LP6226 must be disabled, or otherwise there would exist a power loop inside the phone.  Quite frankly, I really don't get it.

Yeah... so it's only me trying to interpret the hardware designer's intent, but I don't think you're "supposed" to provide power to pogo pin #5.

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.

So of course, it's _possible_ to configure yourself into a bad situation where we're basically trying to consume power from the USB port while also trying to supply it.

For the Pinephone, we would get ourselves into this situation if we provided power to pogo pin #1 or to the USB C port, and if we at the same time enabled the LPW5206. However, the LPW5206 _shouldn't_ be enabled unless a connected USB device convinces the PMIC to enable it. (I don't know the details of USB OTG negotiates that, but it might be via pull ups/downs on the D+/- pins, and/or an extra "ID" pin for USB OTG?)

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 made the assumption that, since USB-5V comes from PS, it's an output only, and providing your own 5V there would be a bad idea because you'd be connecting two power sources together (the Pinephone's PS, plus your external supply at pogo pin #5). However, now I'm also noticing the diode D600, which I suppose could actually protect PS from USB-5V.

You're right, a charger shouldn't be connected in case power is provided through the pogo pin #5 (USB-5V), but I don't think that the purpose of the D600 diode is to create some sort of power inputs separation.  That diode is a part of the LP6226 reference design.

Totally agree, I don't think that is D600's "purpose", since it's part of the reference design and probably required to do the voltage boost. (I'll stay away from analog circuit design haha)

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.

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.

It's almost just up to interpretation at this point, since the Pinephone hardware designers haven't told us what their intent was with pogo pin #5.

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

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.

If the DCIN (or VBAT on the wiki page) went straght to the phone battery, an external batttery could be simply connected in parallel, at least in theory, leaving the charging to the PMIC with no need for additional charging logic, etc.  By the way, I've completely ignored the need to monitor the internal temperature of the external battery, which migh render the reuse of PMIC-based charging impossible.

While it would be entirely possible to wire things up that way, it would be dangerous to do so.

I'll expand on your example of monitoring temperature. Consider this example: the Pinephone's battery is almost dead at 3.4 V, and your external battery is fully charged at 4.2 V. You connect the external battery directly to VBAT. Now, the external battery discharges directly into the Pinephone's internal battery, and at an alarmingly high current. There's nothing the PMIC charger can do to stop this exchange; the PMIC might notice the battery's temperature is increasing (via the thermistor) and decide to stop charging; but too bad, the batteries are directly wired together and nothing can stop it from catching on fire.

So I'm glad that the battery isn't directly exposed via the pogo pins.

The inefficiency thing in converting voltages, I'm not so worried about. Nobody besides the PMIC's battery charger should be able to directly charge the battery at battery voltage. Otherwise, it'd be unsafe, and there would be no way to control which source is charging.

Please, keep in mind that the external batttery would be pretty much unreachable and uknown to the PMIC.  Thus, additional logic for battery charging (and more, as already described) would be required in the keyboard case.

Exactly, and the external battery _should_ be unreachable and unknown to the PMIC. Yes, there must be additional battery charging logic in the keyboard case for its own battery.

I don't see a way around it.

Actually, I wonder if the ACIN and VBUS power input pins on the PMIC should just be isolated from each other. In other words, pogo pin #1 should go to one of those, and the USB C port should go to the other. The PMIC is supposed to seamlessly switch between one or the other (and the battery) as a power input.

That might actually be the right solution, but the problem of charging the external battery would still remain, requiring separate charging circuitry.

Totally agree.

By extension, I guess I would hope that it's safe to draw 1.5 A from USB-5V. If not, then it seems like nothing else prevents us from drawing too much current via the pogo pin or USB port and heating/damaging something.

Maybe the PMIC also monitors current and is able to turn off PS. Otherwise, after the LP6226 "turns off" due to overcurrent, I suppose you could actually still draw more even more current than 1.5 A. It just wouldn't be boosted, so it would be at battery voltage instead of 5 V. Maybe then, the LPW5206 would turn off. I don't know.

The LPW5206 would prevent only more than 500 mA (or 1 A) from flowing into the phone, not out.  Furthermore, I really don't see in the schematic how would it be possible to draw current from both the LP6226 and the battery though the pogo pin.

Actually, it's unspecified whether it's limiting current into or out of the phone. But my interpretation is that its intended purpose is to limit current going out the USB C port.

Imagine if pogo pin #5 didn't exist. Now, the only purpose of the LPW5206 is to limit current going _from_ USB-5V _to_ DCIN. This is so that when it's in USB host mode, the Pinephone can provide a power _output_ through DCIN, which goes out the USB C port. And LPW5206's job (besides enabling/disabling this connection) is to make sure that too much current doesn't go out.

And actually, this is yet another problem for a "pogo pins expansion board" that wants to provide power to the Pinephone via pogo pin #1. If the phone goes into USB "host" mode and decides to drive DCIN, now you have a different two power sources shorted together: your expansion board, and the Pinephone itself. Yikes?

Furthermore, I really don't see in the schematic how would it be possible to draw current from both the LP6226 and the battery though the pogo pin.

The options aren't between the LP6226 or the battery. The only choice is PS. PS itself is provided by either ACIN/VBUS on the PMIC (which is DCIN), or by the battery.

That's why we observe a difference in that voltage depending on whether or not a charger is connected. If a charger is not connected, then PS is battery voltage. If a charger is connected, then PS is the charger voltage (with a small voltage drop).

The option is only that the LP6226 _may_ boost PS up to 5 V, if it is enabled. If it's not enabled, then the voltage is just PS.

(I don't think I misinterpreted the fact that current still flows across D600 even when the LP6226 is disabled. We can test the LP6226's enable to confirm, as discussed.)

---

Totally agree, I don't think that is D600's "purpose", since it's part of the reference design and probably required to do the voltage boost. (I'll stay away from analog circuit design haha)

Actually yeah, D600 is a zener diode. I suppose the way this works is, D600's "breakdown voltage" is the voltage that we're trying to boost to, which is 5 V. So if we were to provide like 5.1 V to pogo pin #5, that still seems bad, since current could still just go backwards through D600 to PS.

So that's more reasoning to suggest that pogo pin #5 is _not_ a power _input_ to the Pinephone.