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

I think that’s the reason why the battery is flipping when the load is still below the PD input power when using 65W charger I’m expecting the flipping is transient due to 51W short burst load, but the battery is flipping all the time. Game for one hour, flip for one hour while the the power from PD is only 45W most of the time. If the PSU is not stabilized the battery will act as a capacitor (parallel to load to absorb high frequency and allow low frequency to the load i.e. CPU, disk, RAM, etc.).

If possible please do the test again with the battery physically removed. The data could provide insights about why the computer can’t draw more than 33W from A 60W PD input

The battery is disconnected in those cases through the bgate mosfet so no overcurrent.

There is no second buck-boost in the 13 and the second one in the 16 is only for 48v to 20.

Not really, standalone mode has so many variables changed to the point where that bcomes pretty much meaningless for this.

If the battery can be disconnected real-time by the EC manipulating BGATE, why I got constant flipping when gaming even after the initial short burst and limited by STAPM, and the power from PD is always 10W less than the charger rating

My earlier test shows otherwise. If using charger of X watts, the laptop can draw Y watts(slightly below X), battery flips above Z watts(significantly blow Y). The laptop won’t draw higher than Z, not Y, when running without a battery

The battery can be disconnected for charging, discharging is allways possible through the body diode of the mosfet. The rest of the ec firmware is also kinda confused at this point.

You may find the rest of this thread enlightening, the using less than the advertised capacity of the charger thing is also something I found in the code and am relatively sure I know what they thought even if I am also pretty sure it doesn’t work like that.

At this point I am reasonably confident that with a combination of fixing the charger current limit calculation, using desired bat voltage instead of current+some offset and making sure bgate stays off when plugged in plus maybe some cpu side power limit tweaks this can be resolved at least for the 13, the power system in the 16 is a whole different beast XD.

I think the ideal solution is, put BGATE MOSFET in parallel to the diode. When charging the battery the MOSFET is conducting, buck boost adjust the voltage and current to provide power to the laptop and charging the battery. When the battery is charged disconnect the MOSFET. If the transient load is too high or the power is disconnected, the diode will conduct. The EC turns on MOSFET after sending the positive voltage drop to reduce losses in the diode, when the load decreases or the power is back on the MOSFET is turned off again.

Bgate HAS a body diode, you can’t really get silicon mosfets without those.

That is literally what already happens.

@Charlie_6
We don’t have a detailed schematic from FW, so we are just assuming they are using a circuit similar to the 2 options in the ISL9241 datasheet.
The FW16 has the “Bypass” diagram.
The FW13 has the diagram without the “Bypass”. The FW13 does not have a “Bypass”.

In this case, there is a BGATE MOSFET that leaves the battery mostly disconnected, until it needs to be charge or discharge it.
The 17800mV (VsysMax) is set to the “desired voltage” as the battery BMS tells us, so reaching that voltage will not harm the battery.
There is a current control on charging the battery, so that reduces the volts below the 17800mV if the charger does not wish to charge the battery.
So, we are not setting Vsys to 17800mV, it is just setting the max limit that Vsys can get to, I.e. limits the max level the buck/boost can get to.
The Vsys also goes through various downstream buck converters before it reaches the CPU/GPU.

So I really need to hack the BMS of my 61Wh battery to let it tell the EC the correct voltage 17800mV instead of the wrong 17600mV

Actually this is a good thing of this EC. It allows third party battery with different chemistry. We are technically able to use NMC or even LFP cells on FL13 as the EC will follow the batterys charging voltage

Exactly, no more 2700/2924/4500mA when connected to a 60W/65W/100W charger

@Charlie_6
If you use my “ectool”, what is the BMS telling you?
ectool battery 0 (Adding the zero adds some more details)

As far as we know, though I don’t know what would be sader, not having ot or having it and not using it XD

Ultimately if the load exceeds the set input current limit regardless of cirquitry you’ll either draw from the battery or crash. We can help that by using closer to the actual limit of the charger instead of capping to 90% for some probably misguided prochot scheme and raising vsys above battery so we have a bit more breathing room to droop before it starts drawing from battery.

Some of the currently reported battery flips may be because vsys is so close to the current battery voltage any quick transient dips into the battery before the charge controller can react.

That bit should be an easy fix once I get my development setup running. Asuming my interpretation of the intentions of the original code here is right.

Once you get the EC CCD and maybe comfortable making your own changes to the EC source code, you can experiment.
All my changes have mostly just been to retrieve more info from the EC to user space.
You have to be careful making changes to the EC code. It only has about 5000 Bytes of free RAM space left, and all the code and data sits in RAM.
So, I try to keep my additions to the EC code as short as possible.
Fortunately, when I was fixing the NORMAL/IDLE/DISCHARGE code, I was deleting lots of bad lines to do it.
So, that is why I try to keep the code small in the EC, and then add any extra stuff to ectool that runs in user space.

That change is likely going to be less code than before XD

But wtf why are they cutting it so close with the program space.

Change 0.9 to 1, removing two bytes(or bits I’m terrible at binary)

$ sudo ectool battery 0
Battery 0 info:
  OEM name:               NVT
  Model number:           FRANGWAT01
  Chemistry   :           LION
  Serial number:          0035
  Design capacity:        3915 mAh
  Last full charge:       3677 mAh
  Design output voltage   15480 mV
  Cycle count             174
  Present voltage         17513 mV
  Present current         1384 mA
  Remaining capacity      3089 mAh
  Desired voltage         17600 mV
  Desired current         2740 mA
  Flags                   0x0b AC_PRESENT BATT_PRESENT CHARGING

I documented it here

Well that bit is getting gone entirely but I do have to deal with the prochot stuff. Imo with a battery input current prochot is unnessecary since we allready have battery current prochot so that would only need to be enabled in standalone mode which I should probably not break if I ever wanted to get that merged upstream (then again the current implementation likely allready hurts standalone more than it helps).

Or more importantly, the two prochots can cause a race condition, possibly leading to “stuck at 400MHz” when one of the prochots fails to turn off

I am pretty sure the input current prochot can’t be triggered in the first place but if it can I someone should really run jameses new register recording command over it.

I found another bug in the EC code yesterday. The EC tells the CPU 3 temps:

  1. APU
  2. Ambient
  3. GPU

The function param is in mK (milli kelvin)
If you don’t have a FW16 GPU, the param is 0 mK.
The K is turned into C in order to send to the AMD CPU via the sb_rmi_mailbox_xfre()
So, it actually tries to tell the CPU that the GPU is -273.150 C.
I don’t know what the CPU will think of that!!!
I modified my code, to simply not send the C to the CPU if it looks too strange, I.e. <-100 C and > 200C.

I have also been seeing if changing PMF settings helps at all.
With a 25 W charger, the 90% lets it deliver only 20W, and then the battery is only able to deliver an extra 20W. With adjusted PMF, I was able to let it pull 20W from the PSU, and 40W from the battery. My FW16 can supply 85W from the battery if it needs to.
So, I think the fix is going to be a mix of PMF changes and Charger PSU current limit changes as well as VsysMax changes.
As it stands today, I think it switches to using battery too soon, when there is still spare PSU capacity.

About the FL16 doing fine with 180W but slows down with 240W, I think that is when gaming with 180W, the power requirement always exceeds the power input so the battery discharges. With 240W, the transient load exceeds 240W but the sustained load is very slight below that and the EC doesn’t know what to do so it keeps prochottin’