Jesse: Can you please file a feedback report? We need system logs to determine what's going on here.

Or generate logs locally on the device and upload to this bug: https://support.google.com/chrome/a/answer/3293821?hl=en

if you file a feedback report, reference issue #876969 so we can search for it.

bleung: May I know which file(s) in the tgz you'd like me to upload?

I extracted the file and took a quick look. Not sure if this helps:
$ grep "charge\|Battery" feedback/cros_ec
<...>
[4648.975373 charge problem: batt params, 0x0 -> 0x1e after 4648.975355s]
[4969.708820 Battery 83% / 14h:24 to empty]
[5633.410752 Battery 82% / 16h:40 to empty]
[6333.106711 Battery 81% / 16h:59 to empty]
[6965.284694 Battery 80% / 13h:9 to empty]
[84077.783280 Battery 74% / 3h:37 to empty]
[84352.929285 Battery 73% / 7h:32 to empty]
[84693.654369 Battery 72% / 7h:55 to empty]
[85159.912016 Battery 71% / 10h:11 to empty]
[85685.627553 Battery 70% / 11h:49 to empty]
[86255.330902 Battery 69% / 10h:57 to empty]
[86828.512498 Battery 68% / 9h:20 to empty]
[87030.581071 charge problem: batt params, 0x1e -> 0x7 after 82381.605698s]
<...>

$ grep "charge problem" feedback/cros_ec
[4648.975373 charge problem: batt params, 0x0 -> 0x1e after 4648.975355s]
[87030.581071 charge problem: batt params, 0x1e -> 0x7 after 82381.605698s]
[135693.775058 charge problem: batt params, 0x7 -> 0x7fc after 48663.193987s]
[135693.788147 charge problem: static update, 0x0 -> 0x1 after 135693.788129s]
[911.063236 charge problem: batt params, 0x0 -> 0x7fc after 911.063219s]

This issue can still be reproduced with today's beta channel update.
Google Chrome	69.0.3497.58 (Official Build) beta (64-bit)
Platform	10895.33.0 (Official Build) beta-channel eve
Firmware Version	Google_Eve.9584.160.0

Please provide the entire feedback log.

bleung: Is there any chance that you can try this on a pixelbook? It can be easily reproduced by just switching channels.

I have a pixelbook but it is fully charged at the moment, so I can't
guarantee i'll be able to give you an answer quickly.

Also, I almost certainly do not have the same legacy charger you have.
Please provide a make and model if you can.

Also, the cable matters too. What A-to-C cable are you using, and are you
*sure* it complies with the USB Type-C specification?

Any charger without PD support will do it. I've tried several, with or without QC2.0/3.0 support.

I have two A-to-C cables, one is from Anker, which I don't know the model, and the other is from iOrange-E[1], which I bought based on your review. :)

[1] https://www.amazon.com/gp/product/B01B7R3WAY/

Since it works with stable channel (67.0.3396.99/10575.58.0), guess it's unlikely a cable issue?

Oh, and you can attach it to the charger even if it's fully charged. Battery keeps draining even when the system is idle.

Thanks for the report, I will take a look.

Hey Duncan,

I reproduced this on Dev Channel, 10991.0.0
with firmware:
Google_Eve.9584.160.0

Powerd thinks it's a 5V 2A DCP charger.

feedback report here: https://listnr.corp.google.com/report/85619382968

Thanks Jesse for the report. I've been able to reproduce this on a recent build on Pixelbook. Current meter says 0A.

BC1.2 charging was broken by this commit: https://chromium.googlesource.com/chromiumos/platform/ec/+/0354ad02cba910c90fd0c0e622c3b0b698802a1c

It is also broken on TOT EC firmware and not just the production branch.

This will need more investigation to see what is going wrong with that patch as it is intended to fix a specific issue with USB state loss on power role swaps.

Ah yes, I remember this CL of Shawnn's. It was intended (and does) fix role swaps with charge-through hubs.

Looking at his code, there may be a bug here.

!pd_capable(port)

Is that a static property of the port, or does that really mean "the port partner has negotiated Power Delivery?"

In this case, since we are connected to a legacy charger via A-to-C cable, we are certainly NOT connected to a port partner capable of PD, but the port itself is PD capable.

I think this logic should not check for PD capable, but instead check to see that the vRd is == DefaultUSB.

vRd-DefaultUSB on the CC pins is the only condition where BC1.2 should be applied. If we negotiate to vRd-1.5 or vRd-3.0, then either USB-C or Power Delivery limits should apply, and we should never do BC.

+shawnn, in case he's still following this.

I think the pd_capable() check is nominally ok as it should only be doing BC12 on a non-PD port, although the PD state does not seem to be known quite yet so the check in usb_hcarger_process() seems to always return that a device is NOT PD capable, even if it is a PD device.

There seems to be an issue where the port is reset after BC12 detection starts, and then for a BC12 charger usb_charge_task() thinks BC12 timed out so it turns it off:

[7.766234 [usb_charger_process] port 1 NOT PD capable, doing BC12 detect]
[7.780136 TCPC p1 Low Power Mode]
[7.780486 TCPC p1 reset!]
[7.800664 TCPC p1 Exit Low Power Mode]
C1 st2
C1 st3
C1 st5
[8.085729 [usb_charger_task]: BC12 timed out, turn off BC12]


For a PD charger the first pd_capable() check in usb_charger_process() indicates it is NOT a PD capable charger (it gets marked as PD capable later)

[84.740826 [usb_charger_process] port 1 NOT PD capable, doing BC12 detect]
[84.864827 [PD_DATA_SOURCE_CAP] port 1 is PD capable]

And because it thinks it is a BC12 port it continuously loops in the usb_charger_task() with BC12 timeout:

[85.063827 [usb_charger_task]: BC12 timed out, turn off BC12]
[85.169308 [usb_charger_task]: BC12 timed out, turn off BC12]
[....repeat forever...]

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/ec/+/bae2fca32f2012e7ba9b16e04c0b1b86b2532570

commit bae2fca32f2012e7ba9b16e04c0b1b86b2532570
Author: Duncan Laurie <dlaurie@google.com>
Date: Mon Aug 27 17:51:41 2018

Revert "bd9995x: Leave USB data switches closed on PD power swap"

This reverts commit 26828c3c3c55673e10bfdd5eee244a5206a1c04f.

This breaks BC1.2 chargers on Eve.

BUG=chromium:876969
BRANCH=eve
TEST=manual test of BC12 charger

Change-Id: I9090ecda77b3474f003b9f564c02e1d6d361fad9
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1191127

[modify] https://crrev.com/bae2fca32f2012e7ba9b16e04c0b1b86b2532570/driver/charger/bd9995x.h
[modify] https://crrev.com/bae2fca32f2012e7ba9b16e04c0b1b86b2532570/driver/charger/bd9995x.c

Sorry for the breakage. Does TCPC low-power mode / port reset cause Rd to be removed or interfere with VBUS, D+, or D- in some other way?

Is there some bit in BD9995X_CMD_INT*_STATUS that we can use to detect that the port entered TCPC low-power mode / port reset? If not, maybe we can send an event to the USB charger task (we may need one unique event per port) when coming out of reset, and have the USB charger task treat it similar to a new VBUS detection?

Decided to do a revert to try and get an updated firmware out, but there are a few things to look at next:

- it seems odd that it would go to low power mode in the first place here, and I I spent a bit of time trying to figure out why but didn't come up with an answer quite yet.

- if there is a good explanation for the low power mode then look at Shawn's suggestions next.

- TOT has a de-bounced LPM entry, but the EVE FW branch does not.  I've mostly been testing on eve branch, but need to check the behavior on TOT to make sure it is the same sequence of events.

- test on Reef (or another similar platform with bd9995x and analogix tcpm) and see if there is a similar issue.  This might indicate whether it is something happening with analogix only and related to it's low power mode or a more generic issue.

Thanks for looking into this.

Since this is labeled M-70, I'm wondering if the commit will also go into 68 and 69?

Does the port enter low power mode after the 5V charger is connected?

No, it doesn't.

Although the low power charging notification shows, as you can see in the original report and comment 15, the charging current is 0A thus it isn't really charging.

Just got 68 through the stable channel, and low-power charging is confirmed to be broken.

Google Chrome	68.0.3440.118 (Official Build) (64-bit)
Platform	10718.88.2 (Official Build) stable-channel eve
Firmware Version	Google_Eve.9584.151.0

For now the fix is targeting M70 because it typically takes a serious security vulnerability to get approval to pull a firmware update into beta/stable channels.

It is possible to charge with a BC1.2 charger with the system off by resetting the EC and keeping it from powering up:  hold the refresh + down arrow keys and press the power button.  It shouldn't result in any visible change as it will intentionally not boot here, but it will let you charge now.  Unfortunately it doesn't help charging while powered on or in suspend.

dlaurie: Yes, I can understand that only serious security fixes can make it to beta and stable channels. It is still sad to see that it will take one or two months until the low-power charging works again. :)

And resetting EC does work.

Thank you for taking time to fix this!

I'm using M70 beta (Build ID 70.0.3538.22) and low-power charging still doesn't appear to work.  Oddly, chrome://power indicates negative power draw, but battery_firmware info indicates that the battery is discharging and I observe zero power draw at the wall outlet.

Was this fix supposed to have landed in my build?  If not, when is it expected on the beta channel?

Dsimcha@

When you are reporting issues on Chrome OS, providing the Chrome version number (70.0.3538.22) is surprisingly not really useful. Chrome versions match to different versions of Chrome OS platform builds numbers.

Please provide the platform and firmware version numbers. The firmware version is the MOST important since that's where Duncan made the fix.

Those numbers are here:
chrome://settings/help/details

dsimcha@

If your Eve has any firmware older than 9584.171.0, it does not have Duncan's revert from comment #22.

Firmware is Google_Eve.9584.160.0.  (Also, platform ID:  11021.19.0).  I guess that explains it.

Do new firmware versions get rolled out with beta OS releases?

Unfortunately I messed up the date calculation for the chrome os release branch point and underestimated the firmware qual schedule, so the update missed the R70 branch and is currently live in R71 instead.

I just encountered this issue and found this bug.  I'm also on Eve firmware 9584.160.0.  It's worth a sanity check to be sure I'm seeing the same bug.

In my case, I'm using my PixelBook at ~80% charge.  I hooked it up to my Anker 20AH power bank using a USB A-to-C cable from the recommended list.

I get the warning notification that I'm hooked up to a low-power charger.  That'd be fine with me - sitting in a cafe somewhere, I'd be happy to just slow the discharge rate.  The charging indicator icon shows charging, but a minute or two later, that indicator disappears.  Similarly, in the shell, the battery_firmware info AC_PRESENT flag is there temporarily, then disappears.

This is the same bug, right?

In my case I can always see the charging indicator icon though it's not really charging.

@#37, sounds like it could be a different bug in that you are disconnecting (AC_PRESENT).  Mind filing feedback (Alt+shift+i) next time it happens and adding 'crbug.com/876969' in the description.

Filed.  Sorry about the delay.

I filed  issue 894036  to avoid polluting this one.

With the firmware in the beta channel (Google_Eve.9584.174.0), low-power charging works without problem.

 Issue 894036  has been merged into this issue.