Pogo pins power clarification - reading schematics

[dsimic]

Please, consider putting the final conclusions into the PinePhone wiki page.

[scholbert]

The confirmed pinout is this:

Code:

PIN6 PIN2 PIN4
PIN1 PIN5 PIN3

Code:

INT  SDA    SCK
DCIN USB-5V GND

Hey bokomaru,
nice examination!
I just was in the mood to rip my phone apart to help you out on this issue, as i read that you done it yourself.

What i wrote down about the "DCIN" net names was just an assumption though... as they seem to be tied together, doesn't matter anyway.
So in the end, we may ask Luke from Pine64 team to finaly confirm what you found out.

Maybe they are willing to share some new mainboard files, to point out the positions and naming of the other testpoints on the board as well.
I started another thread, covering this... but no answer so far.

It should be open as they claim

Good work bokomaru!!

Best regards,
scholbert

[bokomaru]

nice examination!

Thank you :-)  And thanks for your input.

After this, my plan is to reassemble the phone and try applying power to pogo pins to confirm.

The phone still seems to work after reassembling ;-)

I did a quick, temporary, low-effort test on DCIN... I split open a USB cable and taped the 5 V and ground wires to the bottom-left and bottom-right pogo pins. The other end is USB A, which I plugged into a power brick.

Ta da! It charges, just like you'd expect to happen if you plugged into USB C. So far, it hasn't caught on fire ;-)

Please, consider putting the final conclusions into the PinePhone wiki page.

Yes, I would like to. We should be careful not to publish information that could damage others' phones, so I will probably wait for a bit more testing and/or confirmation from others. So far I think we got it right though!

Anyone else interested in taking a "risk" and charging your phone via pogo pins?

So in the end, we may ask Luke from Pine64 team to finaly confirm what you found out.

And of course I would prefer if someone from the Pine64 team would confirm what they intended in their design.

What i wrote down about the "DCIN" net names was just an assumption though... as they seem to be tied together, doesn't matter anyway.

Yeah. I'm still curious why they are named "DCIN" and "DCIN ", but we'll probably never know. Maybe the hardware designer had to work around something. Maybe it means something, I don't know.

Maybe they are willing to share some new mainboard files, to point out the positions and naming of the other testpoints on the board as well.
I started another thread, covering this... but no answer so far.

It should be open as they claim

Totally agree! Fortunately, the limited/outdated info didn't prevent me from figuring this one out. But we should still have access to the info, since this is an "open" hardware project where the community develops the software.

[dsimic]

Ta da! It charges, just like you'd expect to happen if you plugged into USB C. So far, it hasn't caught on fire ;-)
Anyone else interested in taking a "risk" and charging your phone via pogo pins?

My apologies for the delayed response.

I'd say that it should be all fine and that you're on the right track.  Otherwise, how is the battery in the recently announced PinePhone keyboard case going to be (dis)charged?  The case connects to the phone only through the pogo pins.

Yeah. I'm still curious why they are named "DCIN" and "DCIN ", but we'll probably never know. Maybe the hardware designer had to work around something. Maybe it means something, I don't know.

That's probably due to the current-carrying capacity of a single pogo pin.  As the single pogo pin probably cannot carry the required current, the only good solution was to use two pogo pins in parallel.

[bokomaru]

My apologies for the delayed response.

I'd say that it should be all fine and that you're on the right track.  Otherwise, how is the battery in the recently announced PinePhone keyboard case going to be (dis)charged?  The case connects to the phone only through the pogo pins.

No worries, I'm not in a rush :-)  Haven't gotten the extra testing in yet that I wanted to do, beyond what I already shared.

Yes exactly, the keyboard case with battery is yet another example of a device that maybe draws power from the Pinephone, but that also _supplies_ power.

Our findings here are basically that one pogo pin is a power input, and the other is a power output. (And it's maybe also acceptable to draw power from the power input pin when it's not at 0 V. For example, you could draw power from the USB C connector through there.)

Yeah. I'm still curious why they are named "DCIN" and "DCIN ", but we'll probably never know. Maybe the hardware designer had to work around something. Maybe it means something, I don't know.

That's probably due to the current-carrying capacity of a single pogo pin.  As the single pogo pin probably cannot carry the required current, the only good solution was to use two pogo pins in parallel.

Nope, the two "DCIN" and "DCIN " nets are both connected to only the one pogo pin. The other pogo pin is "USB-5V" and connects somewhere else and has a different purpose. There aren't any two pogo pins that are connected to the same place to increase current-carrying capacity.

When we were talking about "DCIN" vs "DCIN ", we were only just trying to guess that maybe the USB C connector wasn't actually on the same net as the one pogo pin. But we were wrong; "DCIN" and "DCIN " are in fact connected together. That's indicated both by the schematics and an experimental connectivity test.

Otherwise, it's also still not clear _what_ the current-carrying capacity is. The wiki says 500 mA in one case, but why is that? Did the author of that just assume that it's 500 mA because that's what one of the USB standards is supposed to provide? Or can somebody show that some component in the schematics actually provides 500 mA (or more, or less)?

[dsimic]

Nope, the two "DCIN" and "DCIN " nets are both connected to only the one pogo pin. The other pogo pin is "USB-5V" and connects somewhere else and has a different purpose. There aren't any two pogo pins that are connected to the same place to increase current-carrying capacity.

When we were talking about "DCIN" vs "DCIN ", we were only just trying to guess that maybe the USB C connector wasn't actually on the same net as the one pogo pin. But we were wrong; "DCIN" and "DCIN " are in fact connected together. That's indicated both by the schematics and an experimental connectivity test.

I've finally managed to go through the PinePhone schematic, so here are my thoughts.

Based on page 9 of the PinePhone 1.2b schematic, pogo pin #1 goes to DCIN, while pogo pin #5 goes to USB-5V.  According to page 6 of the schematic and the AXP803 (PMIC) datasheet, DCIN is the phone's USB power source.  Also, PS on the schematic is the "combined" system power source produced by the PMIC.  On page 6 of the schematic, USB-5V is generated from PS using a LP6226, which is a DC/DC converter configured for 5 V at its output, providing up to 1.5 A.

Thus, the pogo pin #5 (USB-5V) provides stabilised 5 V on USB-5V, up to 1.5 A, which can also be switched on and off using a GPIO line on the SoC.  I do not see the use of that GPIO line in the PinePhone DTS file.

According to page 13 of the schematic, USB-5V (which equals to both the pogo pin #5 and the LP6226 output) go to the input of a LPW5206, which is a current-limiting power switch.  The output of the LPW5206 goes to DCIN, while this power path is enabled or disabled using the N_VBUSEN pin on the PMIC, which should be associated with the USB OTG mode.  This power path is disabled by default, using a pull-down resistor.

Thus, the pogo pin #5 (USB-5V) can also be used as a USB power source, depending on the OTG state of the phone's USB port.

This is very strange.  I really don't know whether this is me misreading the schematic, or a bug in the schematic, but I cannot figure out why should the pogo pin #5 behave differently depending on the mode of the phone's USB port (current sink or source)?

The pogo pin #1 (DCIN) is connected directly to the phone's USB power input (i.e. USB charger).  Again, this is very strange because the wiki page states that one of the pogo pins (VBAT) is connected to the battery, which simply isn't right.  Again, it might be just me misreading the schematic, so please correct me if I'm wrong.

If my findings are correct, the recently announced keyboard case will need to have built-in logic for the battery charging, using 5 V from the DCIN pogo pin, as well as the logic for boosting the battery voltage to 5 V while discharging it and feeding power back to the DCIN pogo pin.  That would be inefficient, but there's no connection to the phone's battery through the pogo pins, so the only way for the keyboard case to exchange power is through the pogo pin #1 (DCIN), which runs at 5 V.

Furthermore, the keyboard case will need to have even more built-in logic that would ensure to stop discharging the case battery upon detecting that a USB charger is connected to the phone, because the case battery must not feed power to the DCIN pogo pin when a USB charger is connected.  This is all rather complicated, pretty inefficient, and, quite frankly, messy. :/

Again, if all this is correct, the wiki page needs to be corrected ASAP.

Otherwise, it's also still not clear _what_ the current-carrying capacity is. The wiki says 500 mA in one case, but why is that? Did the author of that just assume that it's 500 mA because that's what one of the USB standards is supposed to provide? Or can somebody show that some component in the schematics actually provides 500 mA (or more, or less)?

Unfortunately, I am not sure about that.  The above-described LP6226 regulator, which when enabled provides 5 V on the USB-5V line, has 1.5 A as the current limit.

[bokomaru]

I've finally managed to go through the PinePhone schematic, so here are my thoughts.

Thanks for giving it a go, it helps to have more people look at this :-)  Do be sure to read through all the previous posts in the thread, too; we've already worked a lot of it out.

I agree with most of what you wrote, but I also have comments.

Thus, the pogo pin #5 (USB-5V) provides stabilised 5 V on USB-5V, up to 1.5 A, which can also be switched on and off using a GPIO line on the SoC.  I do not see the use of that GPIO line in the PinePhone DTS file.

Yes it _can_ be, but also, to be clear, pogo pin #5 is not _always_ a stabilised 5 V. We've confirmed that by measuring with a multimeter. Like you said, the LP6226 can be enabled/disabled. If a power source is not plugged into the USB C port, nor attached to pogo pin #1, and if the LP6226 is disabled (which apparently it was when I tested), then pogo pin #5 will basically be equal to PS, which is basically battery voltage in this case. (Probably why the wiki is confused)

I'm sure it depends on which version of Linux kernel source you're looking at. But I do know that the person who runs xnux.eu has a 5.9 kernel that uses PD8 (PD8-VCC5V_EN) in sun50i-a64-pinephone.dtsi.

xnux/megous cgit (In the future, when this link breaks, I originally found this repository linked from https://www.xnux.eu)

Code:

reg_usb_5v: usb-5v {
    compatible = "regulator-fixed";
    regulator-name = "usb-5v";
    regulator-min-microvolt = <5000000>;
    regulator-max-microvolt = <5000000>;
    gpio = <&pio 3 8 GPIO_ACTIVE_HIGH>; /* PD8 */
    enable-active-high;
};

Thus, the pogo pin #5 (USB-5V) can also be used as a USB power source, depending on the OTG state of the phone's USB port.

This is very strange.  I really don't know whether this is me misreading the schematic, or a bug in the schematic, but I cannot figure out why should the pogo pin #5 behave differently depending on the mode of the phone's USB port (current sink or source)?

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 :-)

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.

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.

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.

My guess at why the Pinephone hardware developers chose to put pogo pin #5 at USB-5V? Because 1) you can still power something while the phone's USB port isn't in host mode, and 2) if we were going to supply 5 V anyway, I guess we may as well reuse the LP6226's that we already need for when we're a USB host.

Of course the funny thing is, we don't always actually supply 5 V there. It's funny to imagine designing a "pogo pins expansion board", where you'll have a regulated 5 V sometimes, but you can't count on it. Sometimes, when the battery is under load and almost dead and the LP6226 is off, you'll only have 3 V :-)

The pogo pin #1 (DCIN) is connected directly to the phone's USB power input (i.e. USB charger).  Again, this is very strange because the wiki page states that one of the pogo pins (VBAT) is connected to the battery, which simply isn't right.  Again, it might be just me misreading the schematic, so please correct me if I'm wrong.

Yup, we've already confirmed it :-)

Yes, pogo pin #1 (DCIN) goes to the PMIC's input ACIN/VBUS.

Yes, the wiki states that one of the pogo pins is "VBAT, which connects to the battery voltage". And yes, it isn't true.

And it gets better: What the wiki calls "5V / VBUS" is actually DCIN. What the wiki calls "VBAT" is actually USB-5V! (See earlier posts where I confirm the physical locations of each pogo pin.)

If my findings are correct, the recently announced keyboard case will need to have built-in logic for the battery charging, using 5 V from the DCIN pogo pin, as well as the logic for boosting the battery voltage to 5 V while discharging it and feeding power back to the DCIN pogo pin.  That would be inefficient, but there's no connection to the phone's battery through the pogo pins, so the only way for the keyboard case to exchange power is through the pogo pin #1 (DCIN), which runs at 5 V.

Furthermore, the keyboard case will need to have even more built-in logic that would ensure to stop discharging the case battery upon detecting that a USB charger is connected to the phone, because the case battery must not feed power to the DCIN pogo pin when a USB charger is connected.  This is all rather complicated, pretty inefficient, and, quite frankly, messy. :/

I agree!

I'm definitely scared of what happens when you attach power supplies to both the USB C port and to pogo pin #1... that's just shorting together two power supplies. I've pointed this out already.

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.

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.

Otherwise, it's also still not clear _what_ the current-carrying capacity is. The wiki says 500 mA in one case, but why is that? Did the author of that just assume that it's 500 mA because that's what one of the USB standards is supposed to provide? Or can somebody show that some component in the schematics actually provides 500 mA (or more, or less)?

Unfortunately, I am not sure about that.  The above-described LP6226 regulator, which when enabled provides 5 V on the USB-5V line, has 1.5 A as the current limit.

Hey, that's at least more info than we had before!

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.

[dsimic]

Thus, the pogo pin #5 (USB-5V) provides stabilised 5 V on USB-5V, up to 1.5 A, which can also be switched on and off using a GPIO line on the SoC.  I do not see the use of that GPIO line in the PinePhone DTS file.

Yes it _can_ be, but also, to be clear, pogo pin #5 is not _always_ a stabilised 5 V. We've confirmed that by measuring with a multimeter. Like you said, the LP6226 can be enabled/disabled. If a power source is not plugged into the USB C port, nor attached to pogo pin #1, and if the LP6226 is disabled (which apparently it was when I tested), then pogo pin #5 will basically be equal to PS, which is basically battery voltage in this case. (Probably why the wiki is confused)

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).  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.

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.

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.

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).

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.

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.

Thus, the pogo pin #5 (USB-5V) can also be used as a USB power source, depending on the OTG state of the phone's USB port.

This is very strange.  I really don't know whether this is me misreading the schematic, or a bug in the schematic, but I cannot figure out why should the pogo pin #5 behave differently depending on the mode of the phone's USB port (current sink or source)?

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.

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.  By the way, the whole thing wouldn't make much more sense even if the input and output of the LPW5206 were switched by mistake in the phone schematic.  Really weird, IMHO.

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.

Quite frankly, no assumptions should be made when it comes to the PinePhone schematic.   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.

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?

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.

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.

Of course the funny thing is, we don't always actually supply 5 V there. It's funny to imagine designing a "pogo pins expansion board", where you'll have a regulated 5 V sometimes, but you can't count on it. Sometimes, when the battery is under load and almost dead and the LP6226 is off, you'll only have 3 V :-)

My guess is that the intention of the DCIN pogo pin is to connect an external battery.  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.

I'm definitely scared of what happens when you attach power supplies to both the USB C port and to pogo pin #1... that's just shorting together two power supplies. I've pointed this out already.

Nothing good can happen, as we've already pointed out.  Hopefully the charger would be smart enough to give up without leaking the magic smoke.

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.

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.

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.

[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.

[dsimic]

I'll need some time to go through your response in detail.

In the meantime, please have a look at the PineEye schematic, which uses the pogo pins.  It simply takes power from both USB-5V and DCIN pogo pins, again with no isolation (yikes!), and uses a separate 3.3 V regulator.

Obviously, PineEye uses 3.3 V for its power supply voltage, which requires it to use a separate buck regulator.  However, some other "pogo mod" requiring 5 V as the power supply voltage would also have to use a separate buck/boost 5 V regulator, which IMHO raises some questions about the phone design.