search

VR-25 / acc

Advanced Charging Controller
https://github.com/Magisk-Modules-Repo/acc
GNU General Public License v3.0
1.75k stars 109 forks source link

Not working on Pixel 5 #78

Closed leifalbor closed 3 years ago

leifalbor commented 3 years ago

I'm guessing it's probably a kernel issue - but either way, here the logs to help troubleshoot.

Module flashes fine in the latest canary version of Magisk, but doesn't seem to actually do anything regardless of configuration (and charging switch) used.

acc-logs-redfin.tar.bz2.zip

TonyApuzzo commented 3 years ago

Still not working with Magisk v21.1 and acc V2020.11.20.

No errors in Magisk log.

Stock build RD1A.200810.022.A4

TonyApuzzo commented 3 years ago

Also not working on the December 2020 update with stock kernel, nor with ElementX 1.0.4 kernel.

NYCJames commented 3 years ago

It also does not work on my Pixel 4a 5G Dec and Jan update

mrDoctorWho commented 3 years ago

I can confirm it doesn't work on Pixel 5, but only after July update. It worked flawlessly before. It seems that all 4 charging switches are unavailable now. Is there anything we can do to make it work again?

VR-25 commented 3 years ago

I'll soon push an update with new charging switches and more.

leifalbor commented 3 years ago

I'll soon push an update with new charging switches and more.

Nice! Hope you're doing well dude - I thought you must have abandoned the entire project!

mrDoctorWho commented 3 years ago

I'll soon push an update with new charging switches and more.

That would be great.

mrDoctorWho commented 3 years ago

I'll soon push an update with new charging switches and more.

Unfortunately, the update doesn't seem to bring any fix to this issue. I also noticed that the acc daemon crashes/stops working for some reason. When I occasionally run "acc" in terminal (or over adb) it says the daemon isn't running, even though I started it like a few minutes ago. Is there any particular logs you'd like to see?

Charging switch test says none of them work, but the Acc App says that dc/input_suspend works, although I didn't notice it affecting charging. UPD: The app says so for any switch, so I guess it's broken.

I'm running latest stock on Pixel 5. I haven't had any issues with acc at all on my old phone (OG Pixel) and Pixel 5 (until the latest firmware update). I also tried ElementalX kernel, but no luck with it either.

VR-25 commented 3 years ago

I'll soon push an update with new charging switches and more.

Unfortunately, the update doesn't seem to bring any fix to this issue. I also noticed that the acc daemon crashes/stops working for some reason. When I occasionally run "acc" in terminal (or over adb) it says the daemon isn't running, even though I started it like a few minutes ago. Is there any particular logs you'd like to see?

~Charging switch test says none of them work, but the Acc App says that dc/input_suspend works, although I didn't notice it affecting charging.~ UPD: The app says so for any switch, so I guess it's broken.

I'm running latest stock on Pixel 5. I haven't had any issues with acc at all on my old phone (OG Pixel) and Pixel 5 (until the latest firmware update). I also tried ElementalX kernel, but no luck with it either.

After the daemon stops, you can grab /dev/.vr25/acc/accd-*.log. Alternatively, run acc -l cat > /sdcard/accd.log

regarding charging control, have you tried a regular adapter (a.k.a., slow charger)?

mrDoctorWho commented 3 years ago

After the daemon stops, you can grab /dev/.vr25/acc/accd-*.log. Alternatively, run acc -l cat > /sdcard/accd.log

Here you go: accd.log.

regarding charging control, have you tried a regular adapter (a.k.a., slow charger)?

I usually use slow wireless charger. When I performed the tests from my last comment my phone was connected to a laptop via USB-A - USB-C cable.

VR-25 commented 3 years ago

Here you go: accd.log.

exitCode=7 means all charging switches are failing - i.e., none of them responds when toggled.

I usually use slow wireless charger. When I performed the tests from my last comment my phone was connected to a laptop via USB-A - USB-C cable.

I see. This really has to do with the kernel. Have you tried voltage and current control? Speaking of current, acc -ss has presets of 0-500 mA. You may want to try the lowest values and see if charging stops or at least slows down dramatically. Monitor changes with acc -i or acc -w1. Regarding voltage, it''s just a matter of testing whether the limit is honored. acc -sv 3920: 3920 millivolts acc -sv -: restore default

P.S., see if changing switchDelay=2 to switchDelay=5 in /data/adb/modules/acc/misc-functions.sh (line 379) solves the charging switch issue. Restart accd after the change. One-line: sed -i '/switchDelay=2/s/2/5/' /data/adb/modules/acc/misc-functions.sh; accd Revert: sed -i '/switchDelay=5/s/5/2/' /data/adb/modules/acc/misc-functions.sh; accd

mrDoctorWho commented 3 years ago

Have you tried voltage and current control?

I tried just now and voltage limit seems to be working. As soon as I set the voltage limit to 3920, it stops charging and current becomes negative (battery voltage is over 4200mV now).

Speaking of current, acc -ss has presets of 0-500 mA. You may want to try the lowest values and see if charging stops or at least slows down dramatically.

No luck with that, though. I tried acc -s --current 10 and it kinda worked. But strange, though. Sometimes current goes up more than 800mA:

  CURRENT_NOW=784302
  CURRENT_NOW=805969
  CURRENT_NOW=-423889
  CURRENT_NOW=-246582
  CURRENT_NOW=-174865
  CURRENT_NOW=-195617
  CURRENT_NOW=-188293
  CURRENT_NOW=6408
  CURRENT_NOW=-53100
  CURRENT_NOW=810242
  CURRENT_NOW=-248413

I didn't notice anything like that with voltage limit.

P.S., see if changing switchDelay=2 to switchDelay=5 in /data/adb/modules/acc/misc-functions.sh (line 379) solves the charging switch issue. Restart accd after the change. One-line: sed -i '/switchDelay=2/s/2/5/' /data/adb/modules/acc/misc-functions.sh; accd Revert: sed -i '/switchDelay=5/s/5/2/' /data/adb/modules/acc/misc-functions.sh; accd

That didn't work. accd says that switches don't work.

VR-25 commented 3 years ago

Interesting! This suggests current works only partially. Very small values are not honored. Now, you may rely on voltage control as is - or use voltage control files as charging switches. Share /dev/.vr25/acc/ch-volt-ctrl-files.

mrDoctorWho commented 3 years ago 
battery/constant_charge_voltage::v000::4300000
bms/voltage_max::v000::4450000
main/voltage_max::v000::4300000
sm7250_bms/constant_charge_voltage_max::v000::4300000
sm7250_bms/voltage_max::v000::4300000
VR-25 commented 3 years ago

redfin_volt.txt acc_latest_snapshot.zip

There you go. Test that list of potential switches - with acc -t /path/to/list (e.g., acc -t /sdcard/Download/redfin_volt.txt. Use the latest acc zip attached.

mrDoctorWho commented 3 years ago 
redfin:/ # acc -t /sdcard/redfin_volt.txt

(!) Charger must be plugged to continue...
(i) Alright, this may take a minute or so...

(!) [battery/constant_charge_voltage 4300000 3300000] won't work

(!) [bms/voltage_max 4450000 3300000] won't work

(!) [main/voltage_max 4300000 3300000] won't work

(!) [sm7250_bms/constant_charge_voltage_max 4300000 3300000] won't work

(!) [sm7250_bms/voltage_max 4300000 3300000] won't work

redfin:/ #
mrDoctorWho commented 3 years ago

Interestingly enough, it seems to be working now, but as strange as I mentioned before with current (goes up to 800+mA for 5 seconds for about once in 10-15 secs). It might be charging till 4200mV and then stops, then voltage drops to 4130mV and in a few seconds it starts charging again. Current battery level is 78%. Config is default.

Update: In about 10 minutes it charged to 79%.

VR-25 commented 3 years ago

Interestingly enough, it seems to be working now, but as strange as I mentioned before with current (goes up to 800+mA for 5 seconds for about once in 10-15 secs). It might be charging till 4200mV and then stops, then voltage drops to 4130mV and in a few seconds it starts charging again. Current battery level is 78%. Config is default.

Update: In about 10 minutes it charged to 79%.

That behavior is expected. With a low voltage limit, the battery level will only go so far. You can rely on this for now.

redfin:/ # acc -t /sdcard/redfin_volt.txt

(!) Charger must be plugged to continue...
(i) Alright, this may take a minute or so...

(!) [battery/constant_charge_voltage 4300000 3300000] won't work

(!) [bms/voltage_max 4450000 3300000] won't work

(!) [main/voltage_max 4300000 3300000] won't work

(!) [sm7250_bms/constant_charge_voltage_max 4300000 3300000] won't work

(!) [sm7250_bms/voltage_max 4300000 3300000] won't work

redfin:/ #

This may be happening because the charging status is inconsistent - i.e., it may be fluctuating. That's not an issue at all. I just have to make acc understand this voltage related logic.

mrDoctorWho commented 3 years ago

That behavior is expected. With a low voltage limit, the battery level will only go so far. You can rely on this for now.

Well, thanks for the help! This is much better than nothing. But what is the right way to fix the problem with charging to the specified percent? Could this be fixed from your side or only from the kernel side?

VR-25 commented 3 years ago

Well, thanks for the help! This is much better than nothing. But what is the right way to fix the problem with charging to the specified percent? Could this be fixed from your side or only from the kernel side?

The right way of fixing it is updating the kernel. From my side, I can only provide workarounds. Those may not satisfy all users.

Here's one more thing for you to try: Upgrade to the latest version and run acc -s s=0 cw=true; accd Analyze charging control (pause, resume) for some time. cw is short for current_workaround.

VR-25 commented 3 years ago

After reading a couple of posts on XDA, it became clear that this is a kernel issue. Recent system updates have introduced it on Pixel devices. (Google trying harder to enforce programmed obsolescence?) Some users are suggesting switching to certain custom kernels, e.g., Proton, ElementalX (not the latest), etc..

Before going down that route, I suggest testing pairs of switches, like so: acc -t dc/input_suspend 0 1 sm7250_bms/charge_disable 0 1

acc -ss: prints a list of known switches. If a pair works, set it with acc -s s="file1 on off file2 on off --", e.g., acc -s s="dc/input_suspend 0 1 sm7250_bms/charge_disable 0 1 --"

leifalbor commented 3 years ago

Does ACCA support adding pairs of switches? If so, how would this need to be formatted into the Add Charging Switch prompt?

VR-25 commented 3 years ago

Does ACCA support adding pairs of switches? If so, how would this need to be formatted into the Add Charging Switch prompt?

file1 on off file2 on off -- e.g., dc/input_suspend 0 1 sm7250_bms/charge_disable 0 1 --

leifalbor commented 3 years ago

No good I'm afraid. Every combination I've tried, ACC reports back won't work. Looks like if I want to use it, I'll have to go looking for a compatible kernel.

VR-25 commented 3 years ago

No good I'm afraid. Every combination I've tried, ACC reports back won't work. Looks like if I want to use it, I'll have to go looking for a compatible kernel.

With accd stopped, have you tried writing to each control file manually and waiting in between (few secs) to see if charging stops? Possibly, some switches work at least intermittently. Again, it's a kernel issue, but we're looking for workarounds here. It almost looks like OEMs have been introducing those kernel bugs intentionally.

gisthere commented 3 years ago

Hi, this works for me: echo 1 > /sys/devices/platform/soc/c440000.qcom,spmi/spmi-0/spmi0-02/c440000.qcom,spmi:qcom,pm7250b@2:google,bms/power_supply/sm7250_bms/charge_disable It also changes _/sys/devices/platform/soc/c440000.qcom,spmi/spmi-0/spmi0-02/c440000.qcom,spmi:qcom,pm7250b@2:google,bms/power_supply/sm7250bms/status to 'Not charging' My build is: RQ3A.210805.001.A1

@VR-25 Could you explain please, why we need pair of switches instead of just one?

PS: Probably this can be useful:

redfin:/sys/devices # ls -la /sys/devices/platform/soc/c440000.qcom,spmi/spmi-0/spmi0-02/c440000.qcom,spmi:qcom,pm7250b@2:google,bms/power_supply/sm7250_bms/
total 0 drwxr-xr-x 4 root root 0 1970-05-21 12:41 . drwxr-xr-x 3 root root 0 1970-05-21 12:41 .. -r--r--r-- 1 root root 4096 2021-08-13 14:06 charge_charger_state -rw-r--r-- 1 root root 4096 2021-08-13 17:12 charge_disable -r--r--r-- 1 root root 4096 2021-08-13 17:03 charge_done -r--r--r-- 1 root root 4096 2021-08-13 14:06 charge_term_current -r--r--r-- 1 root root 4096 2021-08-13 14:06 charge_type -rw-r--r-- 1 root root 4096 2021-08-13 07:35 constant_charge_current_max -rw-r--r-- 1 root root 4096 2021-08-13 07:35 constant_charge_voltage_max -r--r--r-- 1 root root 4096 2021-08-13 14:06 current_now lrwxrwxrwx 1 root root 0 2021-08-13 16:19 device -> ../../../c440000.qcom,spmi:qcom,pm7250b@2:google,bms -r--r--r-- 1 root root 4096 2021-08-13 14:06 fcc_stepper_enable -r--r--r-- 1 root root 4096 2021-08-13 14:06 health -rw-r--r-- 1 root root 4096 2021-08-13 07:35 input_current_limited -r--r--r-- 1 root root 4096 2021-08-13 14:06 online drwxr-xr-x 2 root root 0 2021-08-13 14:06 power -r--r--r-- 1 root root 4096 2021-08-13 14:06 present -r--r--r-- 1 root root 4096 2021-08-13 14:06 recharge_soc -rw-r--r-- 1 root root 4096 2021-08-13 14:06 rerun_aicl -r--r--r-- 1 root root 4096 2021-08-13 14:06 resistance_id -r--r--r-- 1 root root 4096 2021-08-13 14:06 safety_timer_expired -r--r--r-- 1 root root 4096 2021-08-13 14:06 status lrwxrwxrwx 1 root root 0 2021-08-13 16:19 subsystem -> ../../../../../../../../../class/power_supply -r--r--r-- 1 root root 4096 2021-08-13 14:06 temp -r--r--r-- 1 root root 4096 2021-08-13 14:06 type -rw-r--r-- 1 root root 4096 2021-08-13 14:06 uevent -rw-r--r-- 1 root root 4096 2021-08-13 07:35 voltage_max -r--r--r-- 1 root root 4096 2021-08-13 14:06 voltage_now drwxr-xr-x 2 root root 0 1970-05-21 12:41 wakeup40 redfin:/sys/devices # cat /sys/devices/platform/soc/c440000.qcom,spmi/spmi-0/spmi0-02/c440000.qcom,spmi:qcom,pm7250b@2:google,bms/power_supply/sm7250_bms/uevent
POWER_SUPPLY_NAME=sm7250_bms POWER_SUPPLY_STATUS=Not charging POWER_SUPPLY_RESISTANCE_ID=9971 POWER_SUPPLY_HEALTH=Good POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=0 POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=4390000 POWER_SUPPLY_CHARGE_CHARGER_STATE=16973825 POWER_SUPPLY_CHARGE_TYPE=N/A POWER_SUPPLY_CHARGE_DONE=0 POWER_SUPPLY_CURRENT_NOW=-6103 POWER_SUPPLY_INPUT_CURRENT_LIMITED=0 POWER_SUPPLY_ONLINE=1 POWER_SUPPLY_CHARGE_TERM_CURRENT=-80 POWER_SUPPLY_TEMP=337 POWER_SUPPLY_VOLTAGE_MAX=4390000 POWER_SUPPLY_VOLTAGE_NOW=4287658 POWER_SUPPLY_SAFETY_TIMER_EXPIRED=0 POWER_SUPPLY_FCC_STEPPER_ENABLE=0 POWER_SUPPLY_CHARGE_DISABLE=1 POWER_SUPPLY_RERUN_AICL=0 POWER_SUPPLY_RECHARGE_SOC=97

VR-25 commented 3 years ago

@gisthere, do sm7250_bms/charge_disable, sm7250_bms/status and the like exist in /sys/class/power_supply/?

Does /sys/class/power_supply/battery/status also change?

Does acc -t sm7250_bms/charge_disable 0 1 work? If not, try the full path.

Some devices (e.g., most MediaTek) require two switches - i.e., both have to be toggled for charging to stop/resume. Some OnePlus phones also require two switches to enable idle mode.

gisthere commented 3 years ago

@VR-25 thanks for the explanation!

do sm7250_bms/charge_disable, sm7250_bms/status and the like exist in /sys/class/power_supply/?

Yes, they exist as symbolic links.

Does /sys/class/power_supply/battery/status also change?

No

Does acc -t sm7250_bms/charge_disable 0 1 work? If not, try the full path.

Seems, it doesn't work. But I noticed, that running 'acc -t ...' switches sm7250_bms/charge_disable from 1 to 0:

redfin:/ # cat /sys/class/power_supply/sm7250_bms/charge_disable
0 redfin:/ # echo 1 > /sys/class/power_supply/sm7250_bms/charge_disable
redfin:/ # cat /sys/class/power_supply/sm7250_bms/charge_disable
1 redfin:/ # acc -t sm7250_bms/charge_disable 0 1

(!) Charger must be plugged to continue... (i) Alright, this may take a minute or so...

(!) [sm7250_bms/charge_disable 0 1] won't work

redfin:/ # cat /sys/class/power_supply/sm7250_bms/charge_disable
0

VR-25 commented 3 years ago

The fact that battery/status does not change, while sm7250_bms/status does, reinforces the idea that the kernel is flawed.

Anyways, we're getting somewhere.

Have you confirmed that charging actually stops when sm7250_bms/status is Discharging or Not charging? What does acc -i curr suggest?

Does sm7250_bms/status also change after toggling battery/input_suspend?

I noticed, that running 'acc -t ...' switches sm7250_bms/charge_disable from 1 to 0:

That's because acc -t restores the default value, 0.

gisthere commented 3 years ago

Have you confirmed that charging actually stops when sm7250_bms/status is Discharging or Not charging? What does acc -i curr suggest?

It seems like it really stops, because the phone becomes colder and percentage of the battery indicator (on the status bar) stops rising BUT:

acc -i curr

Battery Service Max charging current: 450000

Uevent CONSTANT_CHARGE_CURRENT=2800000 CURRENT_AVG=4272 CURRENT_NOW=6408 INPUT_CURRENT_LIMITED=0 CURRENT_NOW=6.408 Amps

the value of CURRENT_NOW is strange. When I again put 0 to sm7250_bms/charge_disable, it becomes 0.289917 Amps.

Does sm7250_bms/status also change after toggling battery/input_suspend?

I couldn't find battery/input_suspend, only dc/input_suspend.

The fact that battery/status does not change, while sm7250_bms/status does, reinforces the idea that the kernel is flawed.

Hope, they will fix it in Android 12

VR-25 commented 3 years ago

Ok, it seems charging does indeed stop. The weird current values are just a unit conversion issue, no big deal (working on that too).

Here's the verdict so far... The kernel is flawed. It does not report the correct charging status in /sys/class/power_supply/battery/status. While we wait for a kernel update, I'll implement a workaround - _invite sm7250_bms/status to the party_.

VR-25 commented 3 years ago

Install and test this build.

Focus primarily on the following commands:

acc -d # disable charging
acc -e; accd # enable charging and start the daemon
acc -i # print battery info
acc -i stat # print charging status
gisthere commented 3 years ago

Didn't help:

130|redfin:/ # acc -d (i) Manual mode

(i) Alright, this may take a minute or so... (i) /data/adb/vr25/acc-data/logs/acc-logs-redfin.tar.bz2

130|redfin:/ # cat /sys/class/power_supply/sm7250_bms/status
Charging 130|redfin:/ # acc -i stat

Battery Service status: 2

Uevent CHARGE_CHARGER_STATE=50397205 STATUS=Charging

acc-logs-redfin.zip

VR-25 commented 3 years ago

Here's another attempt to fixing the broken charging status. This versions also lets you use voltage control files as charging switches. That said, acc -ss has a new preset, 3600. It limits voltage to 3600 in order to stop charging. Essentially, whenever disable_charging() is called, voltage is limited to 3600 millivolts. Keep mind that while limiting voltage may not always change the charging status, it still prevents charging past the set threshold. That's essentially what I call pseudo idle mode. The battery works as a power buffer.

accv2021.8.17(202108170).zip

VR-25 commented 3 years ago

accv2021.8.20(202108200).zip

giga-infinity commented 3 years ago

accv2021.8.20(202108200).zip

This fixed my issue with recent versions not working on pixel5. Thank you VR-25!!

77Rudi commented 3 years ago

On Pixel 4a it also runs since v2021.8.17 with 3600 preset. Thank you!!

VR-25 commented 3 years ago

It seems the official kernel fix isn't coming anytime soon. We can't expect Google to care enough about this anyway.

I'm glad major progress has been made! Yes, the workaround I implemented targets all devices with this issue. Those who have been relying on a voltage setting may also try acc -t, since the regular charging switch approach should work as well.

mrDoctorWho commented 3 years ago

It seems that it stopped working again after September update.

VR-25 commented 3 years ago

https://github.com/VR-25/acc/files/7138273/acc_v2021.9.9.1_.202109091.zip Try that.

VR-25 commented 3 years ago

https://github.com/VR-25/acc/files/7143322/acc_v2021.9.10_.202109100.zip

mrDoctorWho commented 3 years ago

I tested these versions, but they don't appear to work. ACC stops working while in the background. It could find a working charging switch, but for some reason still stops working:

 # acc -t

(!) Charger must be plugged to continue...
(i) Alright, this may take a minute or so...

(!) [/sys/devices/platform/soc/soc:google,charger/charge_disable 0 1] won't work

(!) [dc/input_suspend 0 1] won't work

(i) [sm7250_bms/charge_disable 0 1] works
- battIdleMode=true
VR-25 commented 3 years ago

https://github.com/VR-25/acc/files/7147378/acc_v2021.9.11_.202109110.zip This build has a rollback feature. To undo an upgrade, simply run acc -b.

If it stops working while in the background, share the output of acc -l tail after the occurrence, before restarting the daemon.

mrDoctorWho commented 3 years ago

This is what I get after acc exists

89: cycle_switches off
60: typeset 'on='
61: typeset 'off='
61: </dev/.vr25/acc/ch-switches
63: read -A chargingSwitch
/data/adb/vr25/acc/accd.sh[549]: chargingSwitch[0]: parameter not set
65: exxit
89: exitCode=1
90: false
90: set +eux
VR-25 commented 3 years ago

Is this really today's build?

Anyway, you can bypass this error by manually setting the working switch with acc -ss.

mrDoctorWho commented 3 years ago

Probably I did not restart the daemon before giving you the logs. Now it should be right:

251: off=1
252: chmod 0644 /sys/devices/platform/soc/soc:google,charger/charge_disable
252: >/sys/devices/platform/soc/soc:google,charger/charge_disable
252: eval echo '$off'
252: echo 1
252: return 1
252: exxit
89: exitCode=1
90: false
90: set +eux

Anyway, you can bypass this error by manually setting the working switch with acc -ss.

I'll try this, thank you.

UPD: Seems like it's working. Thanks!