Pogo pins power clarification - reading schematics

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