I am just curious about the implementation, @James3 identified the issue and implemented a proposed fix (and I also found and tested a bunch of things on the 13 side but most of the work was done by james) so I want to know what frameworks approach looks like.
on the 13 its caused by:
Kinda excessive p3 power limit (big spikes)
Only setting the input current limit to 90% of negotiated (more spikes)
The weird constantly changing the target battery voltage thing (frequent tiny charge/discharge cycles)
The changelog on the 16 sounds like they may have adjusted p3 (or made per profile p3 limits work which would probably be the best solution, set it to max and get balls to the wall with battery dipping and balanced and powersave donât). Well weâll see eventually unless they choose now to stop releasing the ec code.
@Matt_Hartley is there anything we can do for framework to actually care about this problem?
Iâm slowly getting quite pissed off, that people here poured in quite a lot of work in debugging and probably even fixing a massive problem with the firmware code of the laptops, and thereâs literally 0 proof that framework even cares to look at it. And I donât see âwe told some of the devsâ as actual proof, but more âwe donât actually careâ.
The week alone I had to open up my FW13 two times, because the shi sub-optimal firmware code aparently decided to throttle my CPU to 400MHz, and the only way to fix that is to unplug the battery.
Instead of launching new hardware, the company should maybe try to get the software part working properly as well. In this case, the community actually did a huge part of the work for free. We would just love to see this actually fixed!
I am part of the debbuging people and I barely care about this (I mostly just wanted to mess with the charge controller and then got a bit carried away), itâs mostly cosmetic. Itâs a shame they arenât picking some of the low hanging fruit here but Iâd much rather have them take a closer look at the pd controller and some much more annoying things like the turbo agressive ocp on the usb ports.
If not fixing it I would very much like some reasoning for the decisions made, a lot of them I can kinda guess but some statement like âWe found charger x will explode if loaded at more than 90% of negotiatedâ or âWe forgot to disable input current prochot when a battery is present so we just underused the psu to reduce prochot stutteringâ or something. There may be some method behind the madnes that we arenât aware of.
Maybe not entirely instead of launching new stuff but if they had very polished firmware that would be a major selling point.
I certainly would like to see it fixed (at least for the non âultimate powerâ profiles)
Guess my response was too much of a backhand slap (to Framework for lack of progress on this) with sarcasm.
It was to answer the question of âcan we really expect them to sift through a 564 post forum threadâ:
Yes. If they want the benefit of the thread, they need to read. Getting an answer of 42 is not an answer, they need to go through the journey, put in the work, to get whatâs important âto themâ. Plus, theyâre supposed to have been âTRACKINGâ this. This needs addressing / focus rather than selling me AI left, right and centre.
Maybe I am misreading sth or misremembering, but in this thread it was concluded that the prochot signal originated from the EC and not the CPU firmware?
Prochot can come from all sorts of places, there is hard and soft prochot too.
Hard prochot (like the charge controller or the vrms use) is a physical wire that can be pulled low by anything connected to it and it is relatively hard to tell who was doing it if you canât ask everyone connected to it if they are doing it over some other channel (i2c in the charge controllers case). Hard prochot may also only be active for very short periods so it is somewhat hard to tell that it even was like in the case of input current prochot because that self resolves very quickly once asserting prochot but leads to some pretty horrific fps graphs.
Soft prochot can either be set by the soc itself or set externally through digital means from everything having access to the right registers.
As much as it sounds like it is related to processor temperatures at least in the case of hw prochot itâs used as a general âAAAAAAAAAAA something is wrong, slow down as much as you can without stoppingâ signal.
If I read this right they were talking about the âPROCHOT_CPU/GPUâ flags you can read in radeontop which are soft prochot. As far as my testing goes hard prochot like when setting input current prochot so low it always triggers never showed up in any software readouts.
I assumed âPROCHOT_CPU/GPUâ were just a readout error as I see them a lot with no related effects.
Pretty sure input current prochot is disabled on the 16 (and imo should also be disabled on the 13 outside of batteryless mode). Battery current prochot is on though so could be that or it is coming from the ec because of some state transition.
On the 13 I donât really have any issues with prochot outside of it probably being the reason why the ec configures the charge controller to use less than the negotiated current. I made my own modified ec code that disables input current prochot with battery present and sets input current limit to 100% negotiated with no negative effects so far (I payed for the whole charger let me use the whole charger XD).
These schematics are super easy to understand. The circuit basically has a input switch for laptops that have both DC5525 and USB-C and for laptops like the Framework with multiple USB-C with charging and 5V output. A four switch synchronous rectified buck-boost converter, and bypass diodes/MOSFETs.
The first one is likely used on USB-C charger as it has a buck-boost for compatibility with lower voltage/wattage charger. The second one is likely used for DC5525 or proprietary chargers that have fixed power rating since thereâs only a buck converter.
The circuit can work in different modes, Iâll use the first schematic for explanation.
Bypass charging: When the IN is greater than the SYS power draw, the power is passed through from the adapter to the main DC rail, excessive available power is used to charge the battery. i.e. BYPSG on, BGATE on, NGATE off.
Hybrid mode: If IN is close to SYS power, BAT can be used to provide supplemental power. Thre are two possible way of doing so. One way is BYPSG off, BGATE on and NGATE on. Input power goes to the buck boost to VBAT then to VSYS. If the power consumption is higher, the battery discharges and vice versa. The other way is BYPSG off, BGATE on and NGATE off, VBAT boosted to VSYS. The actual mode is depend on the best voltage range for VSYS.
Discharge mode: If the input is absent or the EC commands a battery discharge, the BYPSG, buck-boost are off and the battery power goes through BGATE and NGATE.
My previous tests:
With a 20V charger without battery the chg_voltage is 15.4V, this suggests that the VIN â VSYS power path might be absent.
We have the schematic from the charge controller already and we are reasonably sure the 13 is missing thy bypass mode (or at least it is never used in the current firmware).
In the case of the 13 it technically has a bi-diractional dc-dc but that is bidirectional for being able to be a pd source which the fw13 canât do for other reasons. As far as I understand the ec firmware boost out of battery is never used.
Since I was able to eliminate battery dips completely on a 100W psu and almost completely on a 60W with only 2 relatively minor changes I am pretty sure we know what the reasons are and just need fixes or justification fro not fixes from framework.
Note the +20V_VADP, +17.6VB, +17.6VB_BATT. The charger used is a ISL9241. According to its spec
Input voltage range: 3.9V to 23.4V (no dead zone)
System/battery output voltage: 3.9V to 18.304V
Bypass mode supported to connect system to adapter
The bypass mode canât be used because 20V is larger than 18.304V, using the BYPSG will fry the VSYS. Thus, 100% of the input wattage goes through the buck-boost.
However there might be a way
USB-C PD Fast Role Swap support and PPS support
With PPS, the laptop can command the charger to support 17.6V5A or 17.6V3A (depend on charger rating, bidirectional buck-boost to 15.48~17.8V battery), or 18.30V to maximize input wattage(bidirectional buck to 15.48~17.8V battery) and enable BYPSG. In this mode, when plugged in, majority of the wattage is bypassed, a low percentage of the input wattage goes through the buck-boost, converting 17.6V to battery voltage bidirectionally. This improves the efficiency significantly.
Since Framework did a BIOS update a while ago on the Intel 11 Gen to support 17.8V battery, itâs theoretically possible to update the EC to support bypass and utilizing PPS. When a non-PPS PD or underpowered(3.3~11V) PPS charger is used, revert to previous mode.
And because the bypass mosfet is likely missing. You could use vadp in pps mode or fixed pd modes lower than 20V.
That is the case on the 13 yeah.
The likely did not put in the bypass mosfet and anyway since the buck converter handles 100W perfectly fine there is little gain to using bypass mode anyway.
The charge controller is just doing what itâs told which is keep the input current below 90% of negotiated and it does that. When it gets there it just lets vsys droop untill the battery takes up the slack which is what causes the higher value intermittent discharges. These can be fixed by both increasing the current limit to closer to 100% of negotiated (and disabling input current prochot when a battery is present cause otherwise that causes issues with >90% input current limit)
Since for reasons that are not quite clear to me vsys is held to the desired battery voltage even when charging is disabled. Since the desired charge voltage kees slightly chaging as the battery reconsiders itâs state of charge this value fluctuates constantly and causes the little mini discharge cycles. These can be fixed by setting vsys higher when not charging. I am not sure why they are doing their own charge current management instead of using the charge controller in the first place but thatâs a different can of worms.
Iâm really at a loss on what to do to make the company take an honest look at this.
@Matt_Hartley is completely ignoring us and support is not really the way to go.
This complete lack of communication together with their most recent PR f-up really is causing me to jump ship to a better laptop manufacturer as soon as one shows up.
Not ignoring you all. However I donât have the cycles available to monitor the forums. Therefore, please work with us in active tickets and weâll be able to focus on each case there.
If you lack an active ticket, please create one so we can focus on the appropriate steps per instance,per customer.
When we have active tickets, we have processes available there to work through the issue and determine the appropriate next steps.
Does that mean thereâs an unpublished solution? Or is per customer just going to their own independent runaround? I would have thought that the solution would be at the product level, as opposed to per customer.
