You were right, the current_now is always equal to current_max
Exactly, the chg_input_current is the only one that runs closed loop. Both the battery’s charging voltage and charging current have steady state error, making charging slower and transition from constant current to constant voltage sluggish. When the computer is sufficiently loaded, the actual current from the USB-C is exactly the chg_input_current (or exactly the current converted by buck converter if 36-48V is used), no steady state error here. However this is the only current that can’t be read from the user whether with upower, ectool or framework-control. Strange.
That is not the one op is asking for, framework put a ina current/voltage sensor on the input that is separate from the one built into the charge controller.
I think i’ve made a breakthrough here: Turns out I was looking at the wrong firmware! My variant of the board (firmware version tulip-4.0.1-9b2a0b1) doesn’t use the INA236 anymore, it uses the BQ25770 made by Texas Instruments!
tldr: check if you’ve got the right board version: sudo ectool version should show RW version: tulip-...
Read raw values using sudo ectool i2cxfer 3 0x09 0 0x35 0x50 0x40 >/dev/null; sleep 0.05; sudo ectool i2cxfer 3 0x09 2 0x25 or sudo ectool adcread 4
The chip seems to be located at bus 3, address 0x09.
When executing sudo ectool i2cxfer 3 0x09 2 0x23 I get back Read bytes: 0xfd 0x26. Converting that to decimal and multiplying it by two (as the datasheet says) yields 19962mV (19.96V, which is pretty much exactly what i’d expect from +20V_VADP).
Raw current seems to be readable using this command: sudo ectool i2cxfer 3 0x09 0 0x35 0x50 0x40 >/dev/null; sleep 0.05; sudo ectool i2cxfer 3 0x09 2 0x25 (WARNING: This pokes at registers in the controller, i’m not responsible if you destroy your hardware)
Decoding those values as int16s gives ~500 to 1200 in idle and 3000 to 4000 under load.
It also seems like the channel the raw I2C poke reads is also hooked up to adc channel 4 on the EC (readable using sudo ectool adcread 4), though I haven’t yet figured out scaling for either.
PS: i’ve never used this editor and i’m running on like 3 hours of sleep, so sorry if it’s kinda incoherent, just ask me if you don’t understand something.
I think it sits behind the buck converter, so it only sees the pd voltage directly if it’s <=20V. (my 20V reading was taken while on a 240W charger with framework_tool reporting 48V/5A negotiated)
The chg_input_current is the “target” current that the charge controller follows, on the input side before the NVDC buck-boost. This is more accurate than battery charging current and voltage so it must have a sensor. However the user can’t read the measured value (opposed to set value) using conventional means. “so close, yet so far” vibe.
48V is not needed for the charge controller because
Yes but that is behind the buck converter, at least on the 7x40hs board there is supposed to be a separate current sensor in front of the buck converter.
The charge controller has it’s own shunts for it to actually do it’s job. James did make a modded ec that got access to those, I played around a bunch with the charge controller on my 13.
That 3 level buck converter is a Renesas RAA489300 living at I2C address 0x4A, also on port 3. And it seems like the current reading on ADC channel 4 of the EC is actually a amplified signal from that buck converter’s current sense line
Now I think we just need someone with a framework that can pull a lot of power (aka has a beefy GPU) and has a current meter to convert that ADC signal to a real, usable, current reading.
For now I think 5 pairs of ADC read → real current read taken across a reasonably large current draw range should be enough to get a good idea.
ADC value can be read using sudo ectool adcread 4
