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
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.
@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
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.
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
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).
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:
APU
Ambient
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’