[TRACKING] Battery flipping between charging and discharging / Draws from battery even on AC

Could also be a weird translation for coil whine (which doesn’t refer to only coils making sound).

So about upower, I just updated to 1.90.9 and reading the gitlab page , it seems that the devs patching the OnBattery issue stops my FW13 from thinking it is connecting and disconnecting from power while being connected to sufficient power (20V 5A) and doing anything heavy on the system like gaming.

It could also be a capacitor that makes noises. Capacitors are made from piezo ceramic, and can operate in a reverse manner to a piezo (ceramic) microphone, i.e. changing the amount of charge in the capacitor makes it change its physical shape, and if the charge is changing regularly, e.g. in filtering the output of a switching regulator, then the capacitor could well be producing noise.

It is an effect very similar to a coil making a noise, in that the stored energy causes changes in the physical dimensions of the device which can be transmitted through the air as sound.

Yeah that’s what I meant, in the english sphere pretty much any noise coming from a pcb gets called coil whine even if it is caused by a capacitor or anything else vibrating. Maybe in whatever language this was translated from they use “capacitor sing” for that generically. That was just a theory though.

OK, linguistic questions aside this change did seem to come from Compal in a Framework-specific commit:

$ git status
On branch fwk-hx20-hx30-4410
Your branch is up to date with 'origin/fwk-hx20-hx30-4410'.

nothing to commit, working tree clean
$ git log -L1728,1731:common/charge_state_v2.c 
commit 73f119696d811ca0d98aa3a21bd384a4b4c1c060
Author: LeoCX_Tsai <LeoCX_Tsai@compal.com>
Date:   Thu Sep 19 15:03:51 2024 +0800

    fwk: implement the battery extender feature
    
    cherry pick Google CLs for battery exceeded
    list:
    [Update EC_CMD_CHARGE_CONTROL to version 2](https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2929340)
    [chgstv2: Add unit test for battery sustainer](https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2987734/4)
    [chgstv2: Add battery sustainer](https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2929347)
    [chgstv2: Refactor charger_discharge_on_ac](https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2986848)
    manual add CLs
    [charge_state: Add EC_CMD_CHARGE_CONTROL V3](https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4824703)
    
    fwk CLs:
    [fwk: override the display charge value for Windows system](https://github.com/FrameworkComputer/ec/pull/1042)
    
    The purpose of this function is to automatically drop the battery max charge voltage if the system is left plugged into AC for a long time to preserve battery life.
    When the timer is exceeded the battery charge voltage should be reduced to 4.35V/cell. Two additional days after the timer has exceeded, the battery charge voltage shall be reduced to 4.3V/cell.
    The timer should reset to 0 days any time the system is in S0/S0ix and not attached to AC for 30 minutes or longer.
    
    BRANCH=fwk-hx20-hx30-4410
    BUG=https://app.clickup.com/t/86eq06zen
    TEST=zmake build hx30 pass
    TEST=trigger extender timer check chg ctl mode is discharge(2) battery also has discharge
    after battery percentage trace to upper value  chg ctl mode change to IDLE
    
    Signed-off-by: LeoCX_Tsai <LeoCX_Tsai@compal.com>

diff --git a/common/charge_state_v2.c b/common/charge_state_v2.c
--- a/common/charge_state_v2.c
+++ b/common/charge_state_v2.c
@@ -1715,0 +1728,4 @@
+        * Some boards have a sing capacitor problem with mode == IDLE. For such
+        * boards, a host can specify EC_CHARGE_CONTROL_FLAG_NO_IDLE, which
+        * makes the sustainer use DISCHARGE instead of IDLE. This is done by
+        * setting lower != upper in V2, which doesn't support the flag.
$ git branch --remote --contains 73f119696d811ca0d98aa3a21bd384a4b4c1c060
  origin/HEAD -> origin/fwk-hx20-hx30-4410
  origin/fwk-hx20-hx30-4410

So hopefully we’ll close all relevant loops here.

Do we know which models the fwk-hx20-hx30-4410 branch addresses?

FW13 Intel 13th Gen i5-1340P: Firmware = hx30
FW13 AMD Ryzen 7840U: Firmware = azalea
FW16 AMD 7840HS: Firmware = lotus

This will tell you which version of EC firmware you have:

sudo ectool version

As a side point. Since I have modified the EC code to not ‘discharge’ so much, I have not seen a FTR or FTH.
So, my changes might be reducing the likelyhood of FTR and FTH. (Freeze then reboot/halt)

It seems that FW are sending changes to the Embedded Controller github repo.
They were mainly sending them to the “hx30” branch, but I was looking at the “lotus” branch, so did not see them until now.

I contacted support, and am going through the support process.

Here’s an important comment from them about expected behavior:

It would be helpful if you could provide guidance about what the intended/expected behavior is supposed to be when plugged in and at the charge limit. Is the machine supposed to still say ‘charging’?

Regarding your query about expected behavior, the battery should ideally remain in a “charged” state when plugged in and having reached the configured charge limit, rather than continuously cycling between charging and discharging. The machine may still display “charging” depending on how the operating system interprets the hardware signals, but it should not draw power from the battery while on AC power under normal conditions.

However, certain factors—such as the specific charger in use, power management configurations, and operating system behaviors—may affect this functionality. The fact that your Nano II 65W[*] and Apple 96W chargers maintain consistent behavior suggests that power delivery plays a role in the issue you’re experiencing with your dock.

*I later managed to reproduce the issue with my Anker 65W Nano II charger

I tool a number of videos reproducing the charge/discharge behavior. I managed to reproduce the charging/discharging flipping, with battery draw, even without the charge limit, with my 65W Anker Nano II, which I think is quite interesting. I see similar behavior with all the 65W chargers I own.

My 96W Apple charger on the other hand seems to supply plenty of juice so the issue never occurred with it.

With all the testing I did (including resetting my mobo), I am now escalating my ticket. I encourage others who are seeing this behavior to open support tickets as well.

I have been experimenting with my own EC source code.
Now that I have stopped the battery doing mini charge/discharge cycles, the battery stays a lot cooler during use, when I have the PSU plugged in.
The touchpad seems to stay a lot cooler.

I have also now implemented support in the EC to tell me what the battery temperature is.

The battery on the FW16 has an internal temperature sensor that is not reported anywhere else. I assume the FW13 is similar.

The battery temp sensor seems to be more accurate than me touching the touch pad to find out how hot the battery is. :slight_smile:

There is limits set for how high the battery can get, and if too hot, it will prevent charging and discharging.

In the EC source code:
./chromium/src/platform/ec/zephyr/dts/bindings/battery:
atl,framework55w.yaml ← The FW13 55W battery charge max = 55 C, discharge max = 70 C
atl,framework61w.yaml ← The FW13 61W battery charge max = 55 C, discharge max = 70 C
atl,framework85w.yaml ← The FW16 85W battery charge max = 55 C, discharge max = 70 C

When I search about Lithium Ion batteries, it tends to say that damage start when charging / discharging > 30 C, but I don’t know what evidence there is for that.

4 Likes

that’s some amazing finds.

I hope FW can test and implement some of your fixes into the official firmware.

As you mention non-exposed battery temps: I noticed that at least the 13gen intel FW13 doesn’t report cooling fan speeds. Is that maybe another thing that is not properly reported to the OS?

Regarding fans:
This should tell you the speed the fans are running at currently.
sudo ectool pwmgetfanrpm all

This should manually switch on all the fans.
sudo ectool fanduty 100

This should switch the fans to auto again.
sudo ectool autofanctrl

1 Like

I have finished the new EC code for the FW16 that fixes all the battery flipping etc. FW13 uses a different code base.
I have let FW know where it is, so hopefully they use it.
I don’t have instructions finished so others can try it safely yet. Maybe next weekend.

2 Likes

Please can someone with a FW 13 post the output of this command:

ectool version

It will tell me which version of the EC firmware a FW 13 runs.
Please also say which FW 13 you have. E.g. AMD 7840U or something else.

I have a Ryzen 7 7840U machine. I am running Arch Linux and BIOS 3.05. Which branch of the Embedded controller do I need to build/what command should I use? In the readme I see this for the Intel boards.

make BOARD=hx30 CROSS_COMPILE=arm-none-eabi-

Will this build ectool? I see a few different options for installing via Arch User Repo, but none of them seem up to date and I am not sure if installing one meant for an Intel machine will cause problems.

Also just for my learning, mostly, would framework-tool work?

I have put some instructions for downloading, compiling and installing “ectool” here:

1 Like

Coming back to this thread…still tracking…into the 3rd year. Does “TRACKING” mean anything anymore?

https://community.frame.work/search?q=%22%5BTRACKING%5D%22%20%23framework-laptop%20in%3Atitle

1 Like

@Second_Coming

Hehe.
Well, after only 2 and a bit years of FW trying to fix it, I have fixed the “flipping” on my FW16 AMD.

I had to edit the EC source code, compile and install it, but at least it is fixed for me.

I will soon create some instructions for others to try it on their FW13.

So, there is hope that soon, we might get a fix for the “flipping” problem.

4 Likes

What is the ectool? Does Framework have an official repo for it?

“ectool” originally came from google.

Various people, including FW and myself and others have forked and edited it to surface some FW specific features.

“sudo ectool help” gives some idea as to what it can be used for.

2 Likes

Got your copy of ectool installed. FW 13 Ryzen 7840U, Arch Linux, BIOS 3.05

$ sudo ectool version
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
RO version:    azalea_v3.4.113353-ec:b4c1fb,os
RW version:    azalea_v3.4.113353-ec:b4c1fb,os
Firmware copy: RO
Build info:    azalea_v3.4.113353-ec:b4c1fb,os:7b88e1,cmsis:4aa3ff 2024-03-26 07:10:22 lotus@ip-172-26-3-226
Tool version:  0.0.1-isolate Apr 25 2025 none
1 Like