Pogo pins power clarification - reading schematics

[GregH]

Hi @bokomaru, yes the changes to the wiki look good - necessarily unclear . The asterix' help denote that the situation is not straightforward.

More generally I think it would be helpful to clarify the name and roles of the "DCIN" and "USB-5V" pins. Here is my suggestion:

USB-C VIN/VOUT (aka DCIN) - pin voltage and role depends on the phone's USB mode (host or device) and is not directly user controllable
DC-VOUT (aka USB-5V) - "always on" output from the phone, +5V when phone is active, otherwise battery voltage (~3.0 to 4.3V)

If the DC-VOUT/USB-5V acts like the +5V rail on the Pine A64 LTS (and probably the A64), the battery can be depleted by having something drawing sub-5V on it (some USB devices will shut themselves off). Might be worth including this as a note, ideally with confirmation from the Pine64 developers.

As for my specific need, I've fallen back to using the "convergence dock" which I can now use for charging the phone much more quickly (higher current) and more reliably with the updated mobian 5.11 patch:
https://forum.pine64.org/showthread.php?...2#pid90802

Many thanks @bokumaru and everyone else who has contributed on this topic

[dsimic]

My apologies for the delayed response.  Also, please be prepared for a very long response.

The problem is more general than that. It's an issue no matter what you connect to pogo pin #1. Doesn't matter if it's an external battery or not, or even whether you're using pogo pin #1 as an input or as an output.

If you are providing power as an input to the Pinephone, then there is the possibility of two power sources being shorted together at DCIN. One from pogo pin #1, the other from the USB C connector.

Another Pine64 device, PineBook Pro, has pretty much the same issue.  It has two power inputs, a barrel plug and a USB Type-C port, and only one power input may be used at a time.  If you use both at once, bad things happen; that's part of the official instructions. 

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?

Why not? :-P The battery can still power something while the A64 is off. You can provide ACIN while the phone is off, too, e.g., you can charge the battery.

I would much rather have all parts of the phone powered off when the A64 SoC is powered off.  Having something actually powered on while the phone is seemingly powered off is a dreaded feature we already have in Android phones.

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.

I've almost always used my PinePhone connected to the official dock, and I felt something was wrong.  I'll explain below.

Well, you're in for a weird surprise.   When the phone is connected to the official dock, and a charger is plugged into the dock, shutting down the operating system causes the phone to power off and, unexpectedly, power back on immediately.  I've tested it more than a few times, and it always (mis)behaves like that.  At the moment, I have no idea why...  Any clues?

(1) Sure, the "nominal" voltage is 3.8 V. But depending on how "full" it is, a lithium polymer/ion battery will range from around 3.4 V to 4.2 V, unloaded. When drawing current, battery voltage dips, and can go as low as 3.0 V or so. This is not specific to the PinePhone; this is based on my knowledge of hobby lithium polymer batteries for radio control electronics.

I totally forgot about the characteristics of li-po batteries, thank you very much for pointing that out.

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.

What should the voltage drop be across D600? We haven't looked it up.

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

Meh, the voltage drop could be investigated. But I don't necessarily think that knowing exactly where the ~ 0.15 V drop comes from is critical to understanding this. There's enough other evidence clearly showing that pogo pin #5's voltage is related to charger or battery voltage.

As you've already pointed out in your later post, D600 is actually a Schottky diode, whose forward voltage drop should be between 0.15 V and 0.45 V, according to Wikipedia.  In fact, a Schottky diode was probably selected for the D600 position because of the low forward voltage drop.  This might actually resolve the doubts about the measured 0.15 V voltage drop.

Anyway, what you're describing is handled by the combination of the AXP803, the ANX7688S, the A64, the LPW5206, and the LP6226. If I remember correctly, there is actually an option (in hardware or in software) to select between the AXP803 or the ANX7688S as the "controller", who senses or decides, for example, when a particular type charger is connected.

Actually, the AXP803 (i.e., the PMIC) handles the "dumb" USB chargers that do not speak the USB Power Delivery (PD) protocol.  If the phone wants to speak to a USB PD charger, and to instruct it to act as a USB PD charger, that must be done via the ANX7688, which in turn lets the PMIC know about higher input current.  The last time I had a look at the ANX7688 driver in the Linux kernel, providing the feedback to the PMIC was not yet implemented.

I really have nothing against that rule, but then what's the actual purpose of the LPW5206?

It has two purposes.

(1) Limit current flowing from USB-5V to DCIN.
(2) Enable/disable the ability for that current to flow at all.

[edit: And the larger purpose is for USB host mode, where the Pinephone supplies 5 V on DCIN, which goes through the USB C connector as an output. I trace the flow of current for that below, from PS to the USB C port.]

Totally agreed.  When the phone's USB Type-C port is not in the USB host mode (i.e., it's in the current sink mode), the LPW5206 must disable the current flow from USB-5V to DCIN, because in that case DCIN serves as the power input to the phone.  The enabling and disabling of the LPW5206 is performed by the PMIC's N_VBUSEN pin.  A pull-down resistor disables the LPW5206 by default.

Then, if you agree, the only missing link is the actual method for the propagation of the change of the USB port to host mode and back to the PMIC.  At the moment, I'm not sure whether the PMIC performs that detection on its own or not.

As a side note, DCIN should've actually been named DCINOUT or something similar, because it acts both as DC input (when the phone is connected to a charger) and as DC output (when the phone acts as an USB OTG power source).  Also, USB-5V should've been named simply DC-5V or PS-5V instead, because it actually has nothing to do with USB.

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.

No, it doesn't. Unless you can show that, for example, 5.3 V at USB-5V would not flow backwards across zener diode D600 to PS, a power source should not be connected as an input to the Pinephone at pogo pin #5.

Totally agreed.  USB-5V (i.e. pogo pin #5) is not intended to be used as power input, and should be used as power output only.  In theory, it might be used as a power input, because it is connected to the input of LPW5206 and the LP6226 can be disabled, but that is not the intended purpose of USB-5V.

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.

No, LPW5206 _is_ connected properly for when the phone is acting as a USB host and is driving the USB C connector's VBUS. IN needs to be on USB-5V, and OUT needs to be on DCIN.

The name "DCIN" is confusing there. It is actually not _only_ a 5V input to the phone. When the phone is a USB host, DCIN is a 5V output from the Pinephone.

Again, totally agreed and I stand corrected.  I already wrote pretty much the same note on the confusing DCIN label, prior to reading your note on the same topic.  That only confirms we're on the same page.

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.

The schematics tell us that pogo pin #5 is not for connecting a power source as an input to the Pinephone. [...]

The IN of the LPW5206 is on USB-5V, and the OUT is on DCIN, allowing current to flow in this direction. If IN and OUT were flipped, the Pinephone would not be able to act as a USB host by driving DCIN.

You're right and, as already noted, now I agree.  Theoretically, USB-5V might be used as a power input, but that is simply not the intended purpose.

Right, there's no isolation between pogo pin #1 and the USB C port; it's the same net. That's the only real functional/safety concern that I have with how the mainboard pogo pins are designed. [edit: Also, no isolation between a power source on pogo pin #1 and the Pinephone's USB host mode]

There is actually an AW338XX on the USB-C small board, which we've talked about before, but I don't think it fixes this problem.

Having no isolation between a power source on the pogo pin #1 (DCIN) and the power output provided to a USB OTG device is a much bigger concern, because it cannot be mitigated by telling a phone user not to connect this or that at the same time.  Moreover, there's no current limiting for the power going from the pogo pin #1 to a USB OTG device, which is even more concerning.

According to its datasheet, AW388XX is simply an overvoltage protection switch, with the intended purpose of protecting the phone from a voltage spike coming in from a misbehaving charger.  Having that protection is good, but it does next to nothing when it comes to what gets out of the phone in OTG mode.

Let's remember, there's no isolation between the power sources inside the phone.

I don't think you meant it that way, but this isn't literally true for all power sources. So to clarify:

There is separation and control for other power sources and power modes. For example, the battery is connected to the PMIC in a different place than the USB C port. And for example, there is sensing and control so that the Pinephone can either act as a USB _host_ by driving the USB C VBUS, or as a USB _device_ by drawing current from there.

Right, the battery is handled and connected on its own.  But, for example there's no isolation between the pogo pin #1 and the charger input.  Adding a couple of isolation diodes with low forward voltage drop should be a simple, inexpensive solution for that issue.

Not a zener diode, it's a "Schottky Rectifier" or "Schottky Diode". (The symbols are similar)
https://en.wikipedia.org/wiki/Schottky_diode
Also see the datasheet for the SS24. (I found one on Digikey or something)

What should the voltage drop be across D600? We haven't looked it up.

See attached screenshot from the SS24's datasheet. The drop will vary with current, and by extrapolating beyond the limits of this graph, at less than 100 mA, the voltage drop is less than 0.25 V; decreasing more as current decreases. I don't know how this interacts with the LP6226; maybe as a whole, the SS24 and LP6226 make up a "perfect" regulator or "super" diode.

It probably does not interact with the LP6226 at all, but the D600 has been selected as a Schottky diode to reduce the forward voltage drop as much as possible for the power flowing from PS, through L606 and D600, and into USB-5V, effectively bypassing the LP6226 in its disabled state.

That being true, _maybe_ you could supply power at pogo pin #5 as an input to the Pinephone, _if_ the LP6226 is disabled. I still don't think it should be done.

That's exactly what I called a theoretical possibility earlier in this post, but that's clearly not the intended purpose.  The only remaining concern is that the pogo pin #5 isn't protected against such misuse.  Again, a cheap protection diode should do the trick.

Unlike for DCIN, there is no "detection" logic that would allow us to determine whether or not an external power source is connected to pogo pin #5. There would have to be cooperation with software to ensure that PD8-VCC5V_EN is "off", and I'm not sure how we would do that, other than by manually controlling it. Or by permanently hogging it to "off", making us unable to act as a USB host while on battery power (no voltage boost to 5 V).

Exactly, the current flow in and out of DCIN has the detecion of the USB OTG mode in place, but the pogo pin #5 has no similar mechanism.  Quite frankly, we shouldn't explore the options for using the pogo pin #5 as power input any further.

On the other hand, why is it actually necessary to have the control mechanism for enabling and disabling the LP6226 at all?  What are the actual use cases that need the disabling of LP6226?  Is the LP6226 disabled when a charger is connected to the phone, because in that case no voltage boost to 5 V should be mandatory?  However, it isn't uncommon for the chargers to provide less than exactly 5 V.

Is the keyboard/battery case using DCIN?

We can only speculate for the time being, but I really don't see what else could it be using.

What if the keyboard/battery case provides power to DCIN, and the Pinephone simultaneously enables USB host mode by turning on the LP6226 and the LPW5206?! Isn't that what would happen?

Let's forget, for the moment, about the issue with the LPW5206 becoming enabled in the current-source mode.

In that case, no pun intended, whatever the amperage keyboard case allows to flow into the phone, will be able to rush out of the phone's USB port operating in current-source mode.  Of course, unless the keyboard case communicates with the phone over I2C, in which case the phone might tell the keyboard case about the switch of the USB port to current-source mode, so the keyboard case can start applying more strict current limiting to DCIN.

Anyway, it would be a bodged solution in any case.  Again, no pun intended.

So two power sources could get shorted together: the Pinephone's LP6226/LPW5206 output, and the keyboard/battery case. All it takes is for the Pinephone to decide to be a USB host, which is what it would do to talk to the convergence dock or a flash drive.

I don't understand how this is OK; maybe I'm missing something. If I'm right about this, and if the keyboard/battery case uses DCIN without some other safety check, then the February update is wrong, and you shouldn't use the Pinephone's USB C port at all.

The output of the LP6226 shouldn't be involved in the whole mess, but in the current-source mode the output of LPW5206 would become shorted to the DCIN coming in from the keyboard case.  As a "solution", the LPW5206 should be always disabled when the keyboard case is attached, which would actually be the only way to make the whole thing work.

Furthermore, with the external power source connected to DCIN, the phone's USB port would provide power all the time, regardless of its operation mode.  Yikes, all that with no proper current limiting, unless the complicated above-described "handshaking" is in place.  However, maybe the reasoning is that no self-powered USB devices would be connected to the phone in that case, similarly to how no USB current-source devices may be connected in that case.

However, why wouldn't it be reasonable to expect that someone wants to connect a self-powered USB hub or a self-powered USB HDD enclosure to the phone?  Not a USB device that acts as a power source, but simply a self-powered USB device.  I'm not sure what would happen if a USB device that expects no power starts receiving power, but probably only the bad things would happen in at least some cases.

In other words, the DCIN net woud become a truly simultaneous DCINOUT with the keyboard case attached.  The power source provided by the keyboard case would be effectively seen as the normal DCIN with a charged attached, while it all would work as no charger is attached and in USB host mode, turning DCIN into simultaneous DCOUT.  I hope that it makes sense.

Could it be that I'm missing something?

Exactly. To me, the extra USB C port feels like a "hacky" solution to work around:

(1) switching between (or simultaneously) drawing power and providing power via pogo pins; as implemented, the keyboard doesn't need to draw power to charge its own battery

Right, the keyboard case could be easily using the power input through the phone's USB port.  That's what DCIN actually is, direct connection to the charger (unless the USB port operates in current-source mode, of course).

In such an arrangement, the only real issue would be that the keyboard case wouldn't be able to easily discern between a charger connected to the phone and the phone providing power to DCIN in current-source mode.  However, that could be resolved by having the phone signal the keyboard case about the switch to currrent-source mode via I2C.

(2) lack of isolation between pogo pin #1 and the USB C port

The problem of isolation between pogo pin #1 and the Pinephone's USB host mode is still unsolved even by this workaround?

In the above-described arrangement, the phone would actually disable the LPW5206 when switching to current-source mode.  The keyboard case, upon the instruction over I2C, would start working as power input to the phone, feeding power into DCIN instead of LPW5206.  The only remaining issue would be having no appropriate current limiting for the power going out of the phone's USB port.

However, the same issue is still present with the separate USB port on the keyboard case. The same "handshaking solution" could also be applied to the above-described arrangement, though.  Unless I'm missing something, of course.

To add USB ports, I would have thought, why not just plug a charger into the convergence dock, or a similar USB C "power delivery capable" hub? Seems like we're not allowed to, though.

To my understanding, a dock might be plugged into the phone's USB Type-C port even with the keyboard case attached to the phone, but no USB charger may be connected to the dock itself.

By the way, the official dock has some issues on capping the maximum input power that's "forwarded" from the connected charger to the phone, which also doesn't behave the same for "dumb" USB chargers and for USB PD chargers.  I haven't researched or tested that in detail yet, though.

* Before attaching the USB device, I found that I could charge via DCIN. Good.
* 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.
* For completeness, I disconnected the USB device and supplied power to DCIN - charging OK.
* While charging I connected the USB device - device would not come up (/dev/ttyUSB*). I have to disconnect the power to DCIN to get the USB device to register.

This is very interesting and rather surprising!  The most intriguing are the third and the fifth bullet points.  I cannot think of anything else but the PMIC behaving differently when a USB device is plugged into the phone, which covers the third bullet point.  Regarding the fifth bullet point, I do not see how the USB device won't register and start while the battery is charging, unless the PMIC again behaves differently and refuses to negotiate the power requirements with the USB device while the battery is charging.

Could you, please, measure the voltage at the "+" pin of the Type-A end of the USB adapter you're using, with the 5 V applied to the DCIN pogo pin and no USB device plugged into the phone?

Also, do you have any "stupid" USB gadgets, such as a USB fan or light, to see if they will work in the scenario described in the fifth bullet point?  Also, could you please recreate the scenario from the third bullet point, using a USB fan or light?  A "stupid" USB gadget should work, and the charging should start, respectively, if my theory about the PMIC behaving differently in those cases is correct.

Of course, we should investigate all that further.

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

This is pretty much the same behavior as with the official dock connected to the phone, which I've described earlier in this post.  We should investigate it, although at the moment I'm not sure where to start from.

Edit: After reviewing the relevant part of the available documentation for AXP803 (i.e. the PMIC), it's clear why this happens with 5 V applied to the DCIN pogo pin. Basically, the PMIC detects the presence of valid input power voltage, which is satisfied in this case, and automatically begins the power-on procedure. However, this doesn't explain the same behavior with the official dock plugged into the phone.

As for my specific need, I've fallen back to using the "convergence dock" which I can now use for charging the phone much more quickly (higher current) and more reliably with the updated mobian 5.11 patch: https://forum.pine64.org/showthread.php?...2#pid90802

This is exactly what I wanted to suggest.  In a few words, if there's power input present on the DCIN pogo pin, bad things can happen if some USB device is plugged into the phone's USB port.

[scholbert]

Hey,

yes this is a long response...
I guess some people who where not formerly involved, would have some difficulties to get it, i guess (no offense, but good thoughts from all of you!!).

So to make it shorter from my side, and hopefully to shed some light on all this again, i just thought it may help to have all parts involved on one sheet.
Maybe a picture says more than 1000 words.  
Hopefully i did not miss anything... so the following is just my best guess again, not trying to go into to much details.
In fact we should try to draw things down a little:

- D600 discussion: this component is just a standard part to make the boost converter based on LP6226 work.
  It is essential for the functionality and to reduce loss it should be a schottky type.

- PMIC in general and the logic inside: Don't forget that there's some kind of a default state machine inside the PMIC to handle evident parts even when coming out of reset.
  The MOSFETs between DCIN and PS inside AXP803 play a decent role as well...
  The other part is all the driver stuff and registers to be set by software later on.
  In other words, you need some useful routines to make it work as it was designed and to not burn things up.

- Pogo-Pin Power Supply Input: AFAIK DCIN should be used, but you'll need to add a schottky diode to protect the power supplies from working against each other.
  The trick would be, to not go higher as 5V with the input voltage at the anode.
  In case a USB Type C charger gets connected the diode would prevent the a current flow form the phone into the breakout.
  If you further take the assumption that USB type C charger delivers 5V, the following would match...
  On the other side, a 5V supply on the breakout board would not be sufficient to overcome forward voltage of the diode to drive against USB Type C charger.

- LPW5206: Just does what it should from my point of view...
  If the PinePhone role switches to host it puts the output voltage of the boost converter to the Type C connector.
  The MOSFETS inside PMIC should not be active then and prevent a flow back in the circuit. This is what the PMIC driver should handle.

- I must admit, that i think as well there are some design flaws inside this phone.

That's it by now... TBC

Cheers,
scholbert

[dsimic]

I'll have a few comments later...  In the meantime, @scholbert thank you very much for the "condensed" exceprt from the PinePhone schematic!  It's nice and very usable when discussing the whole thing about the pogo pins.

Edit: Here's another weird "feature" of the keyboard case...  With no additional "handshaking" between the phone and the keyboard case, the phone would actually never be able to turn itself off while the keyboard case is attached!   By design, the keyboard case would pretty much always provide 5 V to the DCIN pogo pin (unless the case battery is drained completely, of course), which in turn would cause the PMIC to automatically power the phone on after it was powered off.

The only way this behevior could be avoided is to have some additional logic in the keyboard case, besides the separate charger, and to have the phone instruct that logic over I2C (i.e. perform the aforementioned "hanshaking") to disconnect the case's power output from the DCIN pogo pin until further "hanshaking" notice, i.e. until the next phone power-on event initiated by the user.  Anyway, it's probably going to be an error-prone mess.

Edit #2: Here's the comment I've mentioned at the very beginning of this response.

- Pogo-Pin Power Supply Input: AFAIK DCIN should be used, but you'll need to add a schottky diode to protect the power supplies from working against each other.
  The trick would be, to not go higher as 5V with the input voltage at the anode.
  In case a USB Type C charger gets connected the diode would prevent the a current flow form the phone into the breakout.
  If you further take the assumption that USB type C charger delivers 5V, the following would match...
  On the other side, a 5V supply on the breakout board would not be sufficient to overcome forward voltage of the diode to drive against USB Type C charger.

Having an isolation diode on the expansion board (connected to the phone via the pogo pins) that provides a power source to DCIN would be good, but another isolation diode would be needed as part of the phone circuitry, in order to provide complete isolation of two power sources.  Relying on the USB charger "overpowering" the expansion board's power source (by providing higher voltage) would be very risky, even if possible at all.

[smaeul]

Hello, I am seeing this forum thread (linked from the wiki) for the first time, and there's a lot of information in it, so I'm not going to try to use quotes.

Yes, DCIN is bidirectional, so the phone can be either a power sink (drawing from PIN1 or from the Type-C port) or a power source. And the A64 can be either a USB OTG host or a device. With USB Type-C power delivery negotiation, those two choices are decoupled. That is why you can charge the phone through the convergence dock, while simultaneously using the dock as a USB hub.

One important piece I have not seen mentioned so far: there is a control loop (implemented fully in hardware in v1.2) that prevents DCIN from being both a power input and output at the same time.

1. DCIN is an input by default, due to the pull-down resistor R1301 on the LPW5206 enable pin. (the LP6226 enable pin should have a pull-down too, oops!)
   
2. The ANX7688 measures the DCIN voltage through the divider at VBUS_DIV8.
   
3. When a USB cable is plugged in, the ANX7688 determines the phone's power role by negotiating over CC1/CC2 and by using the measured DCIN voltage.
   
4. If it decides the phone should be a power source (making DCIN an output), it drives VBUS_CTRL high. This does two things (see the bottom of page 13 of the schematics):
   • It enables the LPW5206, allowing current to flow from USB-5V to DCIN.
     
   • This is the key here! It drives N_VBUSEN on the AXP803 high. This is an input pin which disconnects VBUS/ACIN1/ACIN2 from PS. In other words, it forces the PMIC to ignore the VBUS voltage and only draw power from the battery.
     
5. If the USB device wants to switch power roles, it must first renegotiate with the ANX7688, which will drive VBUS_CTRL low at the proper time to switch DCIN back to being an input.
   
6. As soon as the USB cable is unplugged, the ANX7688 chip is powered off. VBUS_CTRL goes Hi-Z, R1301 pulls DRVVBUS and N_VBUSEN back low, and DCIN goes back to being an input.
   

On Braveheart and earlier revisions, neither the ANX7688's VBUS_CTRL pin nor the PMIC's N_VBUSEN pin were connected to anything (R1300 was NC). So this same control loop is implemented in software:

• ANX7688 interrupts the A64 and tells it over I2C if it should be a power source or sink.
  
• The A64 uses PD6 to turn the LPW5206 on or off.
  
• The A64 sets REG30[2] inside the PMIC to enable or disable the VBUS to PS path.
  

Either way, there is no situation where USB-5V is allowed to supply PS.

If you want to play with this VBUS-to-PS path, there is a second, independent way it can be disabled: REG30[7] in the PMIC, which is mapped by the Linux driver to /sys/class/power_supply/axp20x-usb/online. Writing 0 to this file disables the DCIN/VBUS input, so you can see what PIN5 does when PS is driven by battery only. (Note: this bit gets reset when DCIN/VBUS stops being supplied with voltage.)

Now, about the pogo pins.

PIN1/DCIN: This pin can be used to provide power to the phone, or to draw power directly from the USB Type-C port (if you only want your peripheral to work while the phone is plugged in). Yes, there is a concern if both PIN1 and the USB port are used as power inputs at the same time. Any peripheral that wants to supply power to PIN1 will need voltage sensing or I2C handshaking to detect when a USB charger is plugged in and stop providing power.

PIN5/USB-5V: This pin should only be used to draw power from the phone. It should not be used to provide power to the phone. In fact, starting with mainboard v1.2, it cannot power the phone, due to the control loop described above. If you drive DRVVBUS high to connect PIN5 to DCIN, you are also telling the PMIC to ignore any power it is receiving from DCIN!

I don't think the fact that PIN5 can be anywhere from VBAT to 5 V is a problem. Providing a dedicated 3.3 V regulator inside the phone would add to the BOM cost, it would decrease the power efficiency for peripherals with a supply voltage below 3.3 V (but with 3.3 V tolerant I/O for I2C), and it would create a hard limit on the supply current. Putting the regulator in the peripheral provides more freedom to choose the right one.

To answer a couple of other questions:

Why did the phone not charge when connected to the variable power supply? One reason is that the PMIC has a minimum voltage, VHOLD, below which it will not charge. On megi's kernels, this is set to 4.5 V. From the datasheet: "VBUS VHOLD is set as max of VBAT+0.15V or 30H[5:3]".

Why would we disable the LP6226 unless using DCIN as an output? That is simple: we do not want to waste battery power by running the boost converter unless it is needed. As mentioned, any peripheral drawing power from PIN5 should be down-regulating it to 3.3 V anyway, so it should not care if the LP6226 is enabled or not. If it does need a 5 V supply, software on the A64 side can request to turn on the boost converter.

Turning off the LP6226 doesn't actually disable USB-5V! Thanks! You found an error in the device tree description. We should be using a GPIO-controlled regulator (i.e. where the GPIO controls the voltage), not a fixed-voltage regulator with a GPIO enable input.

[megous]

Hello, I am seeing this forum thread (linked from the wiki) for the first time, and there's a lot of information in it, so I'm not going to try to use quotes.

Yes, DCIN is bidirectional, so the phone can be either a power sink (drawing from PIN1 or from the Type-C port) or a power source. And the A64 can be either a USB OTG host or a device. With USB Type-C power delivery negotiation, those two choices are decoupled. That is why you can charge the phone through the convergence dock, while simultaneously using the dock as a USB hub.

One important piece I have not seen mentioned so far: there is a control loop (implemented fully in hardware in v1.2) that prevents DCIN from being both a power input and output at the same time.

1. DCIN is an input by default, due to the pull-down resistor R1301 on the LPW5206 enable pin. (the LP6226 enable pin should have a pull-down too, oops!)
   
2. The ANX7688 measures the DCIN voltage through the divider at VBUS_DIV8.
   
3. When a USB cable is plugged in, the ANX7688 determines the phone's power role by negotiating over CC1/CC2 and by using the measured DCIN voltage.
   
4. If it decides the phone should be a power source (making DCIN an output), it drives VBUS_CTRL high. This does two things (see the bottom of page 13 of the schematics):
   • It enables the LPW5206, allowing current to flow from USB-5V to DCIN.
     
   • This is the key here! It drives N_VBUSEN on the AXP803 high. This is an input pin which disconnects VBUS/ACIN1/ACIN2 from PS. In other words, it forces the PMIC to ignore the VBUS voltage and only draw power from the battery.
     
5. If the USB device wants to switch power roles, it must first renegotiate with the ANX7688, which will drive VBUS_CTRL low at the proper time to switch DCIN back to being an input.
   
6. As soon as the USB cable is unplugged, the ANX7688 chip is powered off. VBUS_CTRL goes Hi-Z, R1301 pulls DRVVBUS and N_VBUSEN back low, and DCIN goes back to being an input.
   

On Braveheart and earlier revisions, neither the ANX7688's VBUS_CTRL pin nor the PMIC's N_VBUSEN pin were connected to anything (R1300 was NC). So this same control loop is implemented in software:

• ANX7688 interrupts the A64 and tells it over I2C if it should be a power source or sink.
  
• The A64 uses PD6 to turn the LPW5206 on or off.
  
• The A64 sets REG30[2] inside the PMIC to enable or disable the VBUS to PS path.
  

Either way, there is no situation where USB-5V is allowed to supply PS.

If you want to play with this VBUS-to-PS path, there is a second, independent way it can be disabled: REG30[7] in the PMIC, which is mapped by the Linux driver to /sys/class/power_supply/axp20x-usb/online. Writing 0 to this file disables the DCIN/VBUS input, so you can see what PIN5 does when PS is driven by battery only. (Note: this bit gets reset when DCIN/VBUS stops being supplied with voltage.)

Now, about the pogo pins.

PIN1/DCIN: This pin can be used to provide power to the phone, or to draw power directly from the USB Type-C port (if you only want your peripheral to work while the phone is plugged in). Yes, there is a concern if both PIN1 and the USB port are used as power inputs at the same time. Any peripheral that wants to supply power to PIN1 will need voltage sensing or I2C handshaking to detect when a USB charger is plugged in and stop providing power.

PIN5/USB-5V: This pin should only be used to draw power from the phone. It should not be used to provide power to the phone. In fact, starting with mainboard v1.2, it cannot power the phone, due to the control loop described above. If you drive DRVVBUS high to connect PIN5 to DCIN, you are also telling the PMIC to ignore any power it is receiving from DCIN!

I don't think the fact that PIN5 can be anywhere from VBAT to 5 V is a problem. Providing a dedicated 3.3 V regulator inside the phone would add to the BOM cost, it would decrease the power efficiency for peripherals with a supply voltage below 3.3 V (but with 3.3 V tolerant I/O for I2C), and it would create a hard limit on the supply current. Putting the regulator in the peripheral provides more freedom to choose the right one.

To answer a couple of other questions:

Why did the phone not charge when connected to the variable power supply? One reason is that the PMIC has a minimum voltage, VHOLD, below which it will not charge. On megi's kernels, this is set to 4.5 V. From the datasheet: "VBUS VHOLD is set as max of VBAT+0.15V or 30H[5:3]".

Why would we disable the LP6226 unless using DCIN as an output? That is simple: we do not want to waste battery power by running the boost converter unless it is needed. As mentioned, any peripheral drawing power from PIN5 should be down-regulating it to 3.3 V anyway, so it should not care if the LP6226 is enabled or not. If it does need a 5 V supply, software on the A64 side can request to turn on the boost converter.

Turning off the LP6226 doesn't actually disable USB-5V! Thanks! You found an error in the device tree description. We should be using a GPIO-controlled regulator (i.e. where the GPIO controls the voltage), not a fixed-voltage regulator with a GPIO enable input.

I have a few things to add:
- 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)
- 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. VBUS_CTRL is not controlled in that case and is always 0 regardless of whatever's connected to VBUS/DCIN on type-C connector. Anyway, when phone is off, there's no issue anyway, since it is not supposed to provide power to VBUS. Only issue is that it will not be able to talk to USB-PD charger and set it up.

[smaeul]

- 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 believe DC from PS is always allowed to pass through L606 and D600 and charge C645/C646 to the PS voltage. It is only when you want to charge the capacitors to a higher voltage that you need U601 pumping charge out its LX pin. (And in that case, L606 prevents the high-frequency charge pulses from backfeeding into PS.)

It may still be possible for current to flow backward through U1302: if DCIN is at 5V, but PS is at VBAT due to disabling the VBUS path with the sysfs knob mentioned above. It would be interesting to try that and measure the voltage at PIN5.

[bokomaru]

Thanks, everyone! Looks like the wiki gave this topic a little more visibility.

Lots of info in the last week, and I won't try to keep up with everything all at once.

@GregH, I'm glad you have a solution via the convergence dock! I don't have an opinion yet about renaming the pogo pins, but it's worth discussing. And by the way, thank you for rolling up your sleeves and physically trying some test cases and sharing with us.

@dsimic, it sounds like you and I are mostly in alignment now, e.g., about USB-5V not being an input. Definitely a long post, so maybe I will follow up later on some points there.

@scholbert, your picture does say more than 1000 words, confirmed :-)  Building on @smaeul's comments, we could add in the ANX7688 to this picture too.

@smaeul, thanks for confirming/describing in your own words DCIN and USB-5V, and for adding new info and answers to this discussion to fill in some of the gaps. Earlier, I did just barely touch on the ANX7688's relevance here, but I didn't understand it this well.


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.

[dsimic]

Yes, DCIN is bidirectional, so the phone can be either a power sink (drawing from PIN1 or from the Type-C port) or a power source. And the A64 can be either a USB OTG host or a device. With USB Type-C power delivery negotiation, those two choices are decoupled. That is why you can charge the phone through the convergence dock, while simultaneously using the dock as a USB hub.

I would suppose that one part of the official dock presents itself to the phone as a self-powered USB 2.0 hub?  As such, does the dock actually draw any power from the phone, when a charger is plugged into the dock?  I assume not, because that would turn DCIN into being simultaneously a power input and a power output.

Also, AFAIK self-powered USB hubs may draw some power from the upstream USB port, but they actually don't have to.

One important piece I have not seen mentioned so far: there is a control loop (implemented fully in hardware in v1.2) that prevents DCIN from being both a power input and output at the same time.

1. DCIN is an input by default, due to the pull-down resistor R1301 on the LPW5206 enable pin. (the LP6226 enable pin should have a pull-down too, oops!)

It seems that it could be fixed in the PinePhone DTS file?  If I'm not wrong, there's an internal pull-down resistor on the PD8 (V17) pin of the A64.

2. The ANX7688 measures the DCIN voltage through the divider at VBUS_DIV8.
3. When a USB cable is plugged in, the ANX7688 determines the phone's power role by negotiating over CC1/CC2 and by using the measured DCIN voltage.
4. If it decides the phone should be a power source (making DCIN an output), it drives VBUS_CTRL high. This does two things (see the bottom of page 13 of the schematics):
- It enables the LPW5206, allowing current to flow from USB-5V to DCIN.
- This is the key here! It drives N_VBUSEN on the AXP803 high. This is an input pin which disconnects VBUS/ACIN1/ACIN2 from PS. In other words, it forces the PMIC to ignore the VBUS voltage and only draw power from the battery.
5. If the USB device wants to switch power roles, it must first renegotiate with the ANX7688, which will drive VBUS_CTRL low at the proper time to switch DCIN back to being an input.
6. As soon as the USB cable is unplugged, the ANX7688 chip is powered off. VBUS_CTRL goes Hi-Z, R1301 pulls DRVVBUS and N_VBUSEN back low, and DCIN goes back to being an input.

Thank you very much for this description!  We have been pretty much ingnoring the ANX7688 so far, and it ties a lot together.

As a note, this entire protection mechanism obviously applies to Type-C USB devices only, but it cannot apply to non-Type-C USB devices.  However, the PMIC should be able to handle different types of non-Type-C USB devices on its own; I'll have a related question later in my response, which should clarify this.

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.

If you want to play with this VBUS-to-PS path, there is a second, independent way it can be disabled: REG30[7] in the PMIC, which is mapped by the Linux driver to /sys/class/power_supply/axp20x-usb/online. Writing 0 to this file disables the DCIN/VBUS input, so you can see what PIN5 does when PS is driven by battery only. (Note: this bit gets reset when DCIN/VBUS stops being supplied with voltage.)

Again, thank you very much for this description!

PIN1/DCIN: This pin can be used to provide power to the phone, or to draw power directly from the USB Type-C port (if you only want your peripheral to work while the phone is plugged in). Yes, there is a concern if both PIN1 and the USB port are used as power inputs at the same time. Any peripheral that wants to supply power to PIN1 will need voltage sensing or I2C handshaking to detect when a USB charger is plugged in and stop providing power.

This is exactly one part the "handshaking" I've predicted to be necessary for the recently announced PinePhone keyboard case.

PIN5/USB-5V: This pin should only be used to draw power from the phone. It should not be used to provide power to the phone. In fact, starting with mainboard v1.2, it cannot power the phone, due to the control loop described above. If you drive DRVVBUS high to connect PIN5 to DCIN, you are also telling the PMIC to ignore any power it is receiving from DCIN!

Could you, please, shed some light on why is R1318 currently NC?  I.e. what (presumably) was the use of PL9-DRVVBUS on the A64 as the way for letting software know that USB-5V is powering DCIN?  Or, was it the way for software to disable the LPW5206, as part of the control mechanism in software?

Also, could you please provide an insigh into what actually happens to the above-described control mechanism when a non-Type-C USB device is plugged into the phone?  Does the PMIC handle everything by itself?  However, if I'm not wrong, the N_VBUSEN pin on the PMIC cannot be an input and an ouput at the same time, which would be required for the PMIC to provide the protection on its own?

Turning off the LP6226 doesn't actually disable USB-5V! Thanks! You found an error in the device tree description. We should be using a GPIO-controlled regulator (i.e. where the GPIO controls the voltage), not a fixed-voltage regulator with a GPIO enable input.

Quite frankly, this is rather confusing.   When the LP6226 is disabled by its EN pin, USB-5V is just not "boosted" to 5 V and equals to PS minus a certain voltage drop, by having the current going from PS, through L606 and D600, and out of USB-5V.  What's the actual relation with the PinePhone DTS file you've referred to?

- 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 believe DC from PS is always allowed to pass through L606 and D600 and charge C645/C646 to the PS voltage. It is only when you want to charge the capacitors to a higher voltage that you need U601 pumping charge out its LX pin. (And in that case, L606 prevents the high-frequency charge pulses from backfeeding into PS.)

It may still be possible for current to flow backward through U1302: if DCIN is at 5V, but PS is at VBAT due to disabling the VBUS path with the sysfs knob mentioned above. It would be interesting to try that and measure the voltage at PIN5.

Earlier experimental measurements (as explained further by @bokomaru in their latest post) performed on the pogo pins confirm that, with the LP6226 (U601) disabled, current may freely go from PS, through L606 and D600, and out of USB-5V.  That's also why a Schottky diode has been selected for D600, for its low forward voltage drop, despite being a "plain" diode in the reference LP6226 design.

Obviously, D600 prevents the current flowing back from USB-5V to PS.  We may safely disregard the case of reaching the breakdown voltage of D600.

[smaeul]

Yes, DCIN is bidirectional, so the phone can be either a power sink (drawing from PIN1 or from the Type-C port) or a power source. And the A64 can be either a USB OTG host or a device. With USB Type-C power delivery negotiation, those two choices are decoupled. That is why you can charge the phone through the convergence dock, while simultaneously using the dock as a USB hub.

I would suppose that one part of the official dock presents itself to the phone as a self-powered USB 2.0 hub?  As such, does the dock actually draw any power from the phone, when a charger is plugged into the dock?  I assume not, because that would turn DCIN into being simultaneously a power input and a power output.

Also, AFAIK self-powered USB hubs may draw some power from the upstream USB port, but they actually don't have to.

The important distinction is between USB PD power sources and power sinks. A hub being "self-powered" vs "bus-powered" isn't really meaningful here, since both of those can still be power sinks. USB PD is rather complicated, but the short version is the initial power "source" end is also the data "host" end, and either power or data swap directions as needed.

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.

One important piece I have not seen mentioned so far: there is a control loop (implemented fully in hardware in v1.2) that prevents DCIN from being both a power input and output at the same time.

1. DCIN is an input by default, due to the pull-down resistor R1301 on the LPW5206 enable pin. (the LP6226 enable pin should have a pull-down too, oops!)

It seems that it could be fixed in the PinePhone DTS file?  If I'm not wrong, there's an internal pull-down resistor on the PD8 (V17) pin of the A64.

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

2. The ANX7688 measures the DCIN voltage through the divider at VBUS_DIV8.
3. When a USB cable is plugged in, the ANX7688 determines the phone's power role by negotiating over CC1/CC2 and by using the measured DCIN voltage.
4. If it decides the phone should be a power source (making DCIN an output), it drives VBUS_CTRL high. This does two things (see the bottom of page 13 of the schematics):
- It enables the LPW5206, allowing current to flow from USB-5V to DCIN.
- This is the key here! It drives N_VBUSEN on the AXP803 high. This is an input pin which disconnects VBUS/ACIN1/ACIN2 from PS. In other words, it forces the PMIC to ignore the VBUS voltage and only draw power from the battery.
5. If the USB device wants to switch power roles, it must first renegotiate with the ANX7688, which will drive VBUS_CTRL low at the proper time to switch DCIN back to being an input.
6. As soon as the USB cable is unplugged, the ANX7688 chip is powered off. VBUS_CTRL goes Hi-Z, R1301 pulls DRVVBUS and N_VBUSEN back low, and DCIN goes back to being an input.

Thank you very much for this description!  We have been pretty much ingnoring the ANX7688 so far, and it ties a lot together.

As a note, this entire protection mechanism obviously applies to Type-C USB devices only, but it cannot apply to non-Type-C USB devices.  However, the PMIC should be able to handle different types of non-Type-C USB devices on its own; I'll have a related question later in my response, which should clarify this.

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

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

PIN5/USB-5V: This pin should only be used to draw power from the phone. It should not be used to provide power to the phone. In fact, starting with mainboard v1.2, it cannot power the phone, due to the control loop described above. If you drive DRVVBUS high to connect PIN5 to DCIN, you are also telling the PMIC to ignore any power it is receiving from DCIN!

Could you, please, shed some light on why is R1318 currently NC?  I.e. what (presumably) was the use of PL9-DRVVBUS on the A64 as the way for letting software know that USB-5V is powering DCIN?  Or, was it the way for software to disable the LPW5206, as part of the control mechanism in software?

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.

Also, could you please provide an insight into what actually happens to the above-described control mechanism when a non-Type-C USB device is plugged into the phone?  Does the PMIC handle everything by itself?  However, if I'm not wrong, the N_VBUSEN pin on the PMIC cannot be an input and an ouput at the same time, which would be required for the PMIC to provide the protection on its own?

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.

Turning off the LP6226 doesn't actually disable USB-5V! Thanks! You found an error in the device tree description. We should be using a GPIO-controlled regulator (i.e. where the GPIO controls the voltage), not a fixed-voltage regulator with a GPIO enable input.

Quite frankly, this is rather confusing.   When the LP6226 is disabled by its EN pin, USB-5V is just not "boosted" to 5 V and equals to PS minus a certain voltage drop, by having the current going from PS, through L606 and D600, and out of USB-5V.  What's the actual relation with the PinePhone DTS file you've referred to?

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.