Exploring the Embedded Controller

[Matthijs_Kooijman]

@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

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

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…

[DHowett]

@Matthijs_Kooijman

that’s superclever

Thanks!

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)_/

[Tim_Theil]

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.

[Tim_Theil]

@anon81945988

You can set the battery to 60% in the BIOS as an example

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.

[Sean_Greenslade]

@Tim_Theil

Is there also a way to change the power or current to charge the battery.

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.

@anon81945988

Another issue is that if you use say a 30W charger that can negotiate the PD protocol it may push the adapter to the limit and if it not a classy adapter may damage it and more.

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.

@anon81945988

To ensure a slow charge you will require a non PD compliant charger so the computer only uses 5V at a max of 3A

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.

[Tim_Theil]

Thank you both for the further explanations.

@Sean_Greenslade

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.

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?

@Sean_Greenslade

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.

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.

[Sean_Greenslade]

@Tim_Theil

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

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.

@Tim_Theil

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?

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.

@anon81945988

Maybe PD works a lot different to QC charging. I was using a dumb 5V 2.4A supply and that seemed to draw max using my Fairphone.

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.

[Sean_Greenslade]

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.

@anon81945988

At 96% I turned the laptop on and the remaining 4% charged in 3 min,

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.

[DHowett]

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.

[xela]

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!).

[DHowett]

Yup, it should work fine!

[Nils]

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?

[Second_Coming]

@Nils

built by itself, without the heavy prerequisites that are required for the full framework-ec repo?

The Framework Laptop's Embedded Controller (EC)

[Nils]

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?

[Nils]

@anon81945988

Interesting I seem to have 60+ watts even when charging form 78 to 100% ?? using default Framework charger.

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.

[matze5800]

I would like to use the power led in windows like a hdd activity monitor.
Does somebody know the address that is used for controlling the leds?
I can’t find it in the EC source…

[Second_Coming]

@matze5800

power led

The Framework Laptop's Embedded Controller (EC)

FrameworkComputer/EmbeddedController/blob/hx20/board/hx20/led.c

[matze5800]

I made a little application that uses DHowetts CrosEC driver for windows and turns the power led into a storage activity indicator.

This is mainly for my own use but if someone misses the hdd led as much as me: https://github.com/Matze5800/fw_led/releases

You have to install the driver first: https://github.com/DHowett/FrameworkWindowsUtils/releases

[prepaidpyramid]

Is it possible to port Zephyr to it?

[DHowett]

@matze5800

I made a little application that uses DHowetts CrosEC driver

THIS IS SO COOL! You’re the first person I’ve heard of who is using my CrosEC driver in any capacity. I realize now that I should probably publish a NuGet package containing the header so that you don’t need to carry around a copy of the source in your repository.

The interface is intended to look a bit like the Linux cros_ec interface so that applications can be roughly portable between the two operating systems.

Please feel free to file issues–or pull requests!–if there’s anything you need.

@prepaidpyramid

Is it possible to port Zephyr to it?

One of the upstream EC maintainers started working on a port of the hx20-specific bits to mainline, which would almost certainly build with Zephyr. His work is here. Nothing may come of it, but it looks like the ChromeOS folks are pretty excited about it.