Exploring the Embedded Controller

Ah okay, I never actually got to the point of looking at NBFC’s tools for making configs since I couldn’t even control the fan by writing to EC registers directly. I’m not super knowledgeable about either NBFC or firmware programming, but yeah from your analysis it does seem like NBFC might not be compatible with the Framework.

Maybe, although in my experience the fan speed seems unrelated to whether the laptop is actually charging or just maintaining the battery level while plugged in. Also, manually lowering the CPU boost aggressiveness by increasing the Speed Shift EPP makes it behave like it does on battery, i.e. the fan remains off even when streaming a high res video. This is the workaround I’m using right now, but it’s definitely not ideal because the fan sometimes still comes on (and stays on for a minute or two) if there’s a moment of high load.

Honestly, this particular thing is a very minor inconvenience, but the point is that it’s never bad to have more options because someone will have some way to make use of them. Having fan control – even through some custom utility if not through NBFC – would be in my opinion a very nice value add to the already extremely customizable nature of the Framework.

1 Like

Honestly this would be a cool lever to have at my command, whether plugged-in or not. Often, when I’m processing something, I’ll slide the Windows power slider (another thing missing in Windows 11, yay regression) over to performance mode, then slide back when it’s done. Or, conversely, when there’s a background task or I’m running low on battery, I’ll slide it to power-saving. Even that isn’t enough sometimes - in desperate times, with prior laptops, I’d edit the power profile to cap the CPU at 25% when something I’m running has a poorly designed tight loop and doesn’t really need the performance it’s demanding.

With the Framework’s new-world architecture, something totally unusual has occurred: there’s no longer any CPU power settings at all available to me. Something wants to run-away? Yeah, it’ll goose the CPU to 3GHz in power-save mode, and ain’t a damn thing I can do to stop it.

It’d be nice to have a tool with such settings available. Especially for a laptop as nerd-friendly as Framework :wink:

No, you can not. That’s my point. (I’m very familiar with all the dials you can turn for power settings - you might think I’m not a noob needing to be pointed to this panel!) This Framework laptop - and my build in particular it seems - seems to have some differences from even other Framework laptops. For example, the default hibernate timing was “20 minutes”. Nobody else had seen that - on a clean install with the Framework driver bundle.

Zero controls. (that “Network connectivity” one is something I even had to hack-in with a registry tweak - and I don’t think it has any effect anyway)

Mine’s a newer one, bought from the store and shipped in a week, no batch number. Has the Tempo audio chip and came to me with BIOS 3.07. For what it’s worth. :man_shrugging:

If you’re not aware, the tool I’m using to adjust CPU behavior is Throttlestop. It can do quite a lot (more than the built-in Windows settings could), and even though it has a lot fewer usable controls on Tiger Lake than it had on previous platforms, you can at least adjust power limits and Speed Shift EPP which might be able to get the behavior you want. If you haven’t already, I would consider taking a look at it to see if it helps you at all.

2 Likes

fw-ec-keyboard-console

this is a custom hook, not built-in. sorry!

7 Likes

@DHowett, you seem to be accessing the EC console, which is pretty much exactly what I’m looking for right now.

Background: I’m investigating Laptop powers *on* after hibernate when unplugging/unpowering dock - #6 by Matthijs_Kooijman and want to verify whether the EC is responsible for powering on the machine. I found the ectool console command that allows reading the console, but the buffer is too small, so the startup overflows the buffer, so I can’t see what happened at poweron. If only I could access the console chan command to disable some of the debug channels, I should be able to see the log from actual startup moment.

I looked at the hardware UART, which has no connector soldered on and it is really tiny, if I would want to try that I should probably get the official connector that’s intended to go there (and even then I’m not sure I would manage to solder that tiny…).

I was wondering how you managed to access the console, and why it curiously seems to be running in a text editor, and then I found your code at Commits · DHowett/framework-ec · GitHub. Hah! You hijacked the keyboard driver in the EC to (when enabled with F12) insert keypresses into the console stream and emit output back into the keyboard, that’s superclever :slight_smile:

Doesn’t really help me, though, since if I am going to flash a custom EC firmware (which I’m a bit hesitant to do, lacking a way to unbrick things if I really mess up), I might as well hardcode disable some console output :slight_smile:

So, do you happen to know if there are any host commands (or other tricks) I could use to capture more output? I looked through the list of host commands, but nothing seemed appropriate…

Edit: I just found your ECTool.efi build and tried to see if that would maybe run early enough to capture the poweron output with its console command, but it’s still drowned in PORT80 log lines, unfortunately…

4 Likes

Thanks! :smiley:

Unfortunately, apart from changing the parameters and building it yourself I don’t see a way to quiet some of the more spammy logs. Nobody updates channel_mask outside of the chan command.

I was thinking that you may be able to use ectool’s i2cread/i2cpassthru to get at the cyp5525’s BOOT_MODE_REASON. It would require some digging and the definitions for what those boot reasons are. However, I don’t think it’ll help with the problem at hand – the cyp5525 is probably coming up because it received power, and that doesn’t explain why the rest of the board is powering on.

\_(shrug)_/

2 Likes

That’s great, I’ll definitely try this out!

Is there also a way to change the power or current to charge the battery. If it can be set to a very low level, you can keep the battery at the same charge state without switching charging on and off.

Thank you for the reply! I’m not sure if what I said was clear.

I mean when I charge the laptop, the charger thats included will charge with 60 Watts power. The question is, can I modify the power of my charger so its charging slower to reduce stress on my battery (e.g. less heat and less rapid expansion).

If i limit the charge at 60% as you mentioned, it will charge with 60W until 60% charge is reached. But if I use 20W to charge it takes more time to charge, but my battery stays cooler.

The short answer to this seems to be “no”, at least not without modifying the EC firmware. The closest thing you can do is to use a lower-power USB PD adapter, but this does introduce the possibility of draining the battery while plugged in if the computer consumes too much power. I can say from my own experience that a 30 watt adapter is fine if you’re using the machine mostly at idle or low CPU, and a 45 watt adapter is fine if you’re maxing out a single CPU core.

But more generally, taking advantage of the charge capacity (SOC percentage) limit and doing fewer charge-discharge cycles will have a much more profound impact on battery longevity than limiting the rate of charge.

Amoun, I have no idea what you mean by a “classy adapter”, but it is perfectly safe to run the Framework laptop from a 30 watt adapter that is USB PD compliant.

Without USB-PD negotiation, you may not even get 3 amps. It’s dependent on both the cables and the configuration of the charger. Using a lower-power PD-compliant adapter is a better solution.

1 Like

Thank you both for the further explanations.

If I understand batteries correctly a draining can only happen if the Voltage of your adapter is smaller than the Voltage of the battery.

I found the topic where the power adapter was introduced: The Power Adapter

It says its a PPS adapter, and if I understood correctly the output current can be programmed. Does this mean someone can program it in a way to be like a 30W adapter?

Ok I agree that maybe in the end this will extend the battery life not very much. I just thought that when users discuss the battery, it might be worth to also look at further details around.

While technically a correct statement for batteries in general, this is not relevant for the Framework. There is a DC-DC converter between the USB-C ports of the computer and the battery, so the input voltage doesn’t have any direct consequence on whether or not the battery is charging.

The input power system of the laptop negotiates with the power adapter to determine what amount of power (wattage) it is allowed to draw. It will then self-restrict the amount of power it draw to stay under that limit. If the laptop begins using more power than the negotiated limit, it will take the excess power from the battery so that it does not exceed its input power limit.

It’s my understanding that the Framework does not make use of the PPS mode. But regardless, it would not need PPS mode to self-enforce a lower power draw than the negotiated maximum. It would, however, require a modification to the EC firmware.

Indeed, QC works differently from PD. A compliant PD sink will never draw more than the negotiated maximum power, and in the absence of a PD negotiation, it will fall back to standard USB power signalling. This could limit you all the way down to 100 mA, or 1 A if you follow the USB 2.0 charging-only spec for shorting D+ and D- together.

1 Like

One thing to be aware of is that the state of charge percentage is always just a best guess. Within the battery there is a battery management system (or BMS) that does a process called “coulomb counting” to track how much electrical charge has entered or left the battery. This measurement process is imperfect, so error can accumulate in the reported value. Additionally, the amount of energy a battery can store will change over time (mostly losing capacity as the battery ages), so what energy level corresponds to “100% charged” will change over time.

These two factors are why you will often see recommendations to do an occasional “battery calibration” process where you allow the battery to drain all the way to 0%, then fully recharge it to 100%. This gives the BMS an opportunity to calibrate the actual capacity of the battery and correct its estimates.

Absent a full calibration, there are known points where a partial calibration can occur. Many batteries will “snap” to 100% when the battery has been sitting at its maximum allowable charge voltage and the charge current drops below a certain threshold. The battery and charger are not doing anything different, it’s just an artifact of the SOC measurement system.

1 Like

Y’all might be better served by discussing this in a separate thread, since it’s diverged quite a bit from a discussion about the embedded controller. :slight_smile:

5 Likes

Hello! Do you know if the ectool in https://github.com/DHowett/framework-ec work with 12th gen mainboards as well?

I came across this thread looking to see if I could control battery levels in user-land on 12th, and it’s not entirely clear if it would work or not (or end up breaking something badly!).

1 Like

Yup, it should work fine!

4 Likes

I’ve looked at the current framework-ec repository and it looks like it has quite a few prerequisites for cross-compiling the firmware. The ectools utility is tucked away in the utils directory, and I assume it does not need cross-compilation. How difficult would it be to extract that one utility from the whole repository so that it can be built by itself, without the heavy prerequisites that are required for the full framework-ec repo?

1 Like

Thanks! Indeed, make utils does the trick, although with a bunch of warnings that one can ignore, as it turns out. It results in a dynamically linked executable ectool, but as far as I can see it’s just linking to the c-library, so once built, the executable should be relocatable and runnable without special environment requirements.

The repo is rather huge (about 150Mb) for such a small tool, but that’s a relatively minor issue. A lot of it is documentation and git history, actually.

At the moment the interface is a bit rough because it’s mainly a generic tool, so there are a bunch of options that don’t actually apply to the Framework EC.

The most useful command is probably the convenience option Dustin added:

 sudo ./ectool --interface=fwk fwchargelimit ...

One option I found that does seem to work as well, and may be useful is:

sudo ./ectool chargecurrentlimit ...

It allows capping the charging rate for the battery. If it is indeed the case that fast charging is a little damaging to Li-ion batteries, it may make sense to lower this a little in situations where charging doesn’t need to be super-fast. Does anyone have insight into what good ranges for the value would be?

I’ve noticed that under normal conditions, Framework is quite happy to charge at a rate of 30-40W so that’s somewhere in the 2600mA range. That means your battery is basically fully charged within 1-2 hours, which is nice. However, there are scenarios where one may be perfectly happy with a much slower rate (e.g., you come home and let it charge overnight). Is there benefit in lowering the cap? Is it possible to damage things by setting the cap higher than it should be?

3 Likes

I’m just referring to the average W you compute by taking the difference in mAh of charge of the battery one minute apart and multiply it by 15.4V/60(h/min) [sticking with 15.4V being the design voltage for the battery]; not the actual power pulled from the wall.

1 Like