Pogo pins power clarification - reading schematics

[bokomaru]

Tying up a loose end, regarding "doesn't stay powered off"...

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.

Nothing wrong there. Connect the charger, let the phone power on, then shut it down from software. Leave the charger plugged in, and ta da! You're charging while the A64 is off.

Another side effect is that the device will not stay off with DCIN powered - no charging while switched off, it keeps booting up again :-(

I can reproduce either behavior, depending on which type of device I connect to the phone's USB C port.

Phone -> USB C to A cable -> old "dumb" power brick -> AC wall outlet: Connecting the first time causes the phone to power on. But I can power the phone off from software, and then it stays "off".

Phone -> convergence dock -> USB C to a cable -> old "dumb" power brick -> AC wall outlet: Connecting the first time causes the phone to power on. After powering off the phone from software,
the phone powers back on; won't stay "off".

anx7688 doesn't do anything unless the pinephone is powered on, so there's some fun to be had when charging via USB-PD chargers when the phone is off.

Maybe that's related to this, i.e., maybe the phone powers on by design, so that USB-PD can be negotiated if applicable.

I also remember reading that, for similar reasons, while charging, Android phones tend to be booted up. At least into the bootloader, and then the bootloader maybe knows to enter a different "charging indication" mode or to "stop here" until X or Y event happens.


Anyways, my point is that either of the two conflicting observations can happen, depending on which hardware you connect. If you want to reproduce my "off" test cases, try using a "dumb" brick without USB-PD.

(If anyone wants to talk about more about this aspect, unless it's related to pogo pins, please consider taking it to a new thread)

[dsimic]

So the answer is "sometimes". If you plug in the dock while not charging, the phone will be the power source. If you then plug a charger into the dock, the dock will request to swap power roles with the phone, but until that happens, the phone is still a power source. Similarly, if you first plug the charger into the dock, and then plug the phone in, the phone will be a power sink and data "device", and the phone has to request a data role swap to become the host.

Thank you for the explanation, and my question was actually about the behavior of the official dock with a charger plugged into the dock.  In that case, the dock should act as a power source and its built-in USB devices should require no power from the phone at all.

Unfortunately that doesn't help. The reason I suggest a pull-down is to keep the LP6226 off while the A64 is completely powered down. In that case, the A64's GPIO pins are all deconfigured.

(When you shut down Linux/the A64, the two power rails that stay on are PS and VCC-RTC. So anything powered by PS should be considered "always on". This was the source of the battery drain bug in v1.1: there was no way to turn off U1301, the regulator supplying the ANX7688.)

Got it now, thanks, and I remember the battery drain bug.  In your opinion, can we expect revision 1.2c of the PCBA, which would include the missing pull-down resistor?  The new PCBA revision could also include a hardware fix for the backlight flicker I've proposed; I would really appreciate if we could discuss the proposed fix.

Quite frankly, I don't like the idea of having parts of the phone actually powered on while the phone is seemingly powered off (RTC is clearly an exception).  That's a dreaded feature already found in Android phones.

According to page 31 of the AXP803 datasheet, it should be possible to use software to turn off the IPSOUT (PS1 and PS2) power outputs entirely upon shutting down the A64 SoC.  According to pages 60, 61, 64 and 65, the states of the 30h and 3Ah registers of the PMIC and, consequently, the regular power sources for the IPSOUT pins, should be restored upon powering the phone on.

How about doing that to make the PinePhone really turned off when it's seemingly powered off?  As far as I can see, that should be a pretty straightforward addition to the axp20x_power_off() function in the Linux kernel driver source.

If requested by the OP, we could also fork this into a separate thread, but this discussion should still be somewhat related to the pogo pins.

Also, what actually ensures that the LP6226 is enabled, which provides "boosted" 5 V at USB-5V, when DCIN works as power output?  The LP6226 should be disabled by default.

The ANX7688 driver in Linux: https://megous.com/git/linux/tree/arch/a...1-1956#n84

Very nice; it's always surprising how much can be done in the device tree specification alone.   To reiterate another part of your response, this also applies to non-Type-C USB devices plugged into the phone, which use an appropriate cable that gets the ANX7688 involved in the handshaking process.

A pogo pin peripheral could reference the regulator in a similar way.

Would that mean than the peripherals attached to pogo pins would need to be defined in the device tree?  That would be rather difficult, but could be left to the work performed by the peripheral driver instead.

I added the circuit in v1.2, but at that point we had no way to test that VBUS_CTRL worked like we expected. I kept the GPIO connection as a fallback so N_VBUSEN could be driven by the A64 if needed, and so we could monitor VBUS_CTRL from the A64. However, I made a mistake: VBUS_CTRL is a 3.3V output. That's fine for the PMIC, where N_VBUSEN is tolerant up to PS+0.3V. However, the PinePhone is designed with a 1.8V I/O on Port L. So VBUS_CTRL would over-drive the other pins on Port L, messing up the backlight brightness -- fixing that is why R1318 was made NC in v1.2b.

Got it, thanks.  Basically, R1318 is a leftover from the development phase.

If a non-PD-capable USB device is plugged in, the phone will always be a power sink (e.g. male A to C cable), or always be a power source (e.g. C to female A cable), depending on the marker resistor inside the cable. It's not possible to plug in a "non-Type-C" device. Type-C cables without a marker resistor are not USB compliant. So the ANX7688 always knows which direction the current is supposed to flow.

The PMIC does connect to the D+ and D- lines to do USB BC current limit negotiation for A-to-C charging, but that is unrelated to source/sink direction.

Thank you very much for describing this.  To reiterate, the appropriate cable gets the ANX7688 involved in the handshaking process.

By the way, there seems to be a power negotiation issue when powering on the phone with no charger connected and connecting a "dumb" (USB BC-compliant) charger later, but I'll research it further before reporting back and proposing a fix.

Simply that the DTS is not accurately representing the hardware. The DTS claims the GPIO is an on/off switch, when it is really a high/low voltage switch. And this leads the driver to use the wrong API to manipulate it. However, the end result is the same: the GPIO is driven high when we are providing power to the Type-C port, and driven low otherwise.

Got it, thanks, the confusion came from the way I interpreted your initial description.  Will there be a bugfix for the DTS file?

Phone -> USB C to A cable -> old "dumb" power brick -> AC wall outlet: Connecting the first time causes the phone to power on. But I can power the phone off from software, and then it stays "off".

Phone -> convergence dock -> USB C to a cable -> old "dumb" power brick -> AC wall outlet: Connecting the first time causes the phone to power on. After powering off the phone from software,
the phone powers back on; won't stay "off".

(If anyone wants to talk about more about this aspect, unless it's related to pogo pins, please consider taking it to a new thread)

As requested, I've created another, separate thread for the discussion about the power sources powering on the phone.  However, it is still somewhat related to the pogo pins, because one of the functions of the pogo pins is to provide power to the phone.

[bokomaru]

Added USB detection + power control to the bottom of @scholbert's collage.

This shows where the ANX7688 looks at CC1/CC2 and DCIN for USB C channel configuration detection, while the AXP803 looks at DP/DM for (dumb) charger detection. Shows where the ANX7688 can decide to turn on VBUS_CTRL, which affects both the LPW5206 and the PMIC.

Even if the ANX7688 says it's ok to use DCIN, the PMIC can still decide not to use it for other reasons.

Thanks @smaeul for explaining how this works!

[scholbert]

Added USB detection + power control to the bottom of @scholbert's collage.

This shows where the ANX7688 looks at CC1/CC2 and DCIN for USB C channel configuration detection, while the AXP803 looks at DP/DM for (dumb) charger detection. Shows where the ANX7688 can decide to turn on VBUS_CTRL, which affects both the LPW5206 and the PMIC.

Even if the ANX7688 says it's ok to use DCIN, the PMIC can still decide not to use it for other reasons.

Thanks @smaeul for explaining how this works!

Yeah!
That's great stuff... i'm sorry but i found no time the last days to do this update.
So thanks for your work!!!

Regards,
scholbert

[bokomaru]

Haha no reason to be sorry, no obligation @scholbert. I liked your idea of the condensed picture, and I hope it helps others to find the right parts to look at to understand things more easily!


I don't think I have many questions left, but at least one thing is still on my mind: What happened with @GregH's phone here?

* I then attached the USB device without supplying power to DCIN. USB device worked fine. Good.
* I then supplied +5V to DCIN. Good new? No magic smoke! Bad news? No charging.

My guess: There is no charging because VBUS_CTRL is high, which means the PMIC ignores its DCIN input. But, there are now two power sources (5 V regulators) connected together at DCIN like this?

Code:

Battery -> PS -> LP6226 -> USB-5V -> LPW5206
                                            \
                                              --> DCIN -> USB C port -> USB device
                                            /
External 5 V source -> pogo pin -----------

Should that be avoided? Similar to how we should avoid connecting 5 V to DCIN while a charger is connected to the USB C port?

@GregH's phone didn't catch on fire. Is that "luck", or is there something about the design that makes this ok or "safe"?

(Note: Now I understand that this doesn't create a "loop" inside the phone, because the PMIC ignores DCIN while the LPW5206 is enabled)

[dsimic]

My guess about why GregH's phone didn't catch on fire would be that the output of LPW5206 was at exactly 5 V, while the external 5 V source was actually slightly below 5 V.  As a result, the output of LPW5206 was able to "beat" the external source, while the external source had some kind of protection (most probably an isolation diode) that prevented power from feeding into it.

Edit: Even if the external 5 V source was at exactly 5 V or even slightly higher, so the output of LPW5206 was unable to "beat" it, our beloved D600 diode prevented the external source from reaching the LP6226 or PS.  However, all this should be avoided, IMHO.

[megous]

I'll only attack one topic today in this post, and I think @smaeul just beat me to it :-P

- USB-5V seems like it should always be 5V if PS-5V is enabled and if it has some other voltage when PS-5V is disabled, it's only because there's some remaining charge on the capacitors, or some current going in the reverse direction via U1302 via internal N-MOSFET body diode (see https://megous.com/dl/tmp/06d11858b841c503.png - there's a parasitic diode between S-D in that direction) You're not supposed to rely on USB-5V in this case, when PS-5V is off (another diode on the PS-5V output prevents backfeeding of power through PS-5V)

I think I can show that the "other" voltage on USB-5V is neither due to a capacitor nor reverse current through U1302. (It really is battery voltage coming from PS across D600)

Phone powered on, no external power attached. Measure USB-5V to be ~ 3.9 V. Connect a 1 k ohm resistor (brown black red) between USB-5V and GND, to draw a few mA of current. Measure voltage at DCIN to be 0 V. Measure voltage at USB-5V to be ~ 3.7 V.

It's not "residual capacitance", because I'm drawing current, and the voltage is constant w/o decaying, even over minutes of time while drawing a few mA of current.

It's not "reverse current" through U1302, because the "reverse source" side of U1302 would be its VOUT, which is the Pinephone's DCIN, which I measured to be 0 V.

So I think that when the LP6226 is disabled, current really does just flow from PS through D600 to USB-5V. Even if that wasn't totally "intended", I don't see why it would be an issue for a pogo expansion board to draw current from USB-5V even while the LP6226 is disabled, since PS is still the source in either case.

Right, I didn't notice the inductor.

[dsimic]

- USB-5V seems like it should always be 5V if PS-5V is enabled and if it has some other voltage when PS-5V is disabled, it's only because there's some remaining charge on the capacitors, or some current going in the reverse direction via U1302 via internal N-MOSFET body diode (see https://megous.com/dl/tmp/06d11858b841c503.png - there's a parasitic diode between S-D in that direction) You're not supposed to rely on USB-5V in this case, when PS-5V is off (another diode on the PS-5V output prevents backfeeding of power through PS-5V)

Actually, the LPW5206 has no parasitic body diode, as specified on page 1 of the datasheet.  Here's a quotation:

A built-in charge pump is used to drive the N-Channel MOSFET that is free of parasitic body diode to eliminate any reversed current flow across the switch when it is powered off.

[bokomaru]

Marking this thread as solved.

Thanks everyone for sharing in the forum, and for editing the wiki. And thanks to the Pine64 organization: it's awesome that we had access to enough information to dig around this much.

I hope that there isn't negativity from this thread. It's easy to find reasons to bash on some complicated design that we don't totally understand ourselves. The PinePhone suits my needs. I'm grateful for the pogo pins and for all the effort that was poured into the hardware and software to make it all work :-)

Original questions from the 1st post, with answers:

1. Is that a good read? Did I get it wrong?
   
   Pretty much a good read, yes. There were other aspects and details that got pointed out, though.
   
   
2. Did I get the pinout right? Why are PIN1 and PIN2 in the middle?
   
   No, DCIN and USB-5V were swapped. The pins were probably numbered in some arbitrary order in the logical schematic, and then moved around into some other arbitrary order for the physical layout.
   
   
3. Does USB-5V/PIN5/VBUS provide a 5V output up to 500 mA?
   
   Yes, but we didn't come up with a firm answer on what the current limit actually is, or what happens when you exceed the limit.
   
   
4. Is DCIN/PIN1/VBAT a 5V input for powering the device and charging the battery?
   
   Yes. It can also be an output. You need to be careful, though. See the wiki page warnings.
   
   
5. What happens if you connect a 5V input to DCIN/PIN1/VBAT and to the USB-C connector at the same time? Would that short together two power sources?
   
   Yes, we think so.
   
   
6. "VBAT, which connects to the battery voltage" would make me think that pogo PIN1 basically connects to the positive battery terminal VBAT. Not true though, right?
   
   Right.
   

And here are wiki page updates as a result of this thread.