Framework 16 | Battery not accepting charge after water spill

Community Support
,
1

OS: NixOS 26.11-unstable

Device: Laptop 16 (AMD Ryzen 7040 Series) (A9)

Hey :slight_smile:

A few days ago, I had a water spill. After opening it up and letting it dry out, my battery no longer accepts a charge.

Based on the framework_tool output, it looks to me like the battery is generally healthy, except for:

Current:       0.000A (avg 0.000A)

My guess is that it’s either be the BMS not accepting charge or an issue with the mainboard’s charging circuit.

Before I purchase new hardware, I thought I’d ask here for some advice.
Is there any more troubleshooting I can do before I order a new battery to try out?

I haven’t noticed any visible corrosion, but there was some moisture below the battery when I opened it up. Thankfully, most of it seems to have been caught by the mid plate.

[Update] framework_tool --smartbattery , after entering the unseal key, gives me:

Enter unseal key in hex (e.g. 04143672), or press enter to skip:
[ERROR] Failed to communicate with EC. Reason: "I2C Transfer not acknowledge

So I guess it’s most likely the BMS?

Here’s the output of the framwork_tool diagnostics:

--smartbattery:

Device Name:   FRANDBAT01
Manuf Name:    NVT
Serial Num:    00C5
Manuf Date:    2025-05-08
Chemistry:     LION
FW Version:    Device=0x0045 FW=09.03 Build=0x4900
Mode:          0x6001
Temperature:   27.6C
Voltage:       12.957V
  Cell 1:      3.233V
  Cell 2:      3.200V
  Cell 3:      3.263V
  Cell 4:      3.262V
Current:       0.000A (avg 0.000A)
Charge:        1% (13 / 5833 mAh)
Design:        5491mAh @ 15.480V
Bat Status:    0x02C0 [DSG (Discharging), INIT (Initialization), RCA (Remaining Capacity Alarm)]
Cycle Count:   42


=== Battery Health Analysis ===


Status: HEALTHY
  No issues detected. Battery is operating normally.


Summary:
  Cycle count: 42
  Capacity: 5833 / 5491 mAh (106%)
  Current cell balance: 63mV spread

--power -vv
Battery Cutoff:     Not cut off
Charger Status
  AC is:            connected
  Charger Voltage:  17800mV
  Charger Current:  5488mA
                    1.00C
  Chg Input Current:7680mA
  Battery SoC:      1%
Battery Status
  AC is:            connected
  Battery is:       connected
  Battery LFCC:     5833 mAh (Last Full Charge Capacity)
  Battery Capacity: 13 mAh
                    0.168 Wh
  Charge level:     0%
  Manufacturer:     NVT
  Model Number:     FRANDBA
  Serial Number:    00C5
  Battery Type:     LION
  Present Voltage:  12.958 V
  Present Rate:     0 mA
  Design Capacity:  5491 mAh
                    85.0 Wh
  Design Voltage:   15.480 V
  Cycle Count:      42
  Battery charging
  Battery level CRITICAL!

--pdports
USB-C Port 0:
  PD Contract:   Yes
  Power Role:    Sink
  Data Role:     Dfp
  VCONN:         Off
  Negotiated:    36.000 V, 5000 mA, 180.0 W
  CC Polarity:   CC2
  Port Partner:  Source
  EPR:           Active (Supported)
  Sink Active:   Yes
USB-C Port 1:
  PD Contract:   No
  Power Role:    Source
  Data Role:     Dfp
  VCONN:         Off
  Negotiated:    5.000 V, 1500 mA, 7.500 W
  CC Polarity:   CC1
USB-C Port 2:
  PD Contract:   No
  Power Role:    Source
  Data Role:     Dfp
  VCONN:         Off
  Negotiated:    5.000 V, 1500 mA, 7.500 W
  CC Polarity:   CC1
USB-C Port 3:
  PD Contract:   No
  Power Role:    Sink
  Data Role:     Ufp
2

I suspect the charge controller has a problem.

Your battery is almost fully discharged(1% charge), I recommend charging it because leaving it fully discharged can accelerate its wear.

You can use a laboratory power supply to charge the battery to 16-ish volts (60-70% charge) and connect it back to the mainboard

Adjust the voltage of your PS to 16.0V, 1A, thenBATT+ to the power supply’s + and GND to the -.
When waiting for charging you can take the time to double-check your mainboard has fully dried and searching for corrosion
After putting the charged battery back to the mainboard run the terminal commands again also run sudo ectool battery

3

Thanks for the suggestion, but that sounds like a potential safety hazard. If it is a BMS safety-lockout, then I’d rather not override it manually.

4

If it’s safety-lockout it should show is the health analysis

There’s an example of an unhealthy battery

I think the best way to figure out what’s the problem is to have another one with an FL16 and swap the battery or the mainboard with the other one

5

The safety_status, etc. are gated behind the unseal command:

if let Some(key) = unseal_key {
        self.unseal(ec, (key >> 16) as u16, key as u16)?;

        data.state_of_health = self.read_bytes(ec, ManufReg::Soh as u16, 4)?;
        data.operation_status = self.read_i32(ec, ManufReg::OperationStatus as u16)?;
        data.safety_alert = self.read_i32(ec, ManufReg::SafetyAlert as u16)?;
        data.safety_status = self.read_i32(ec, ManufReg::SafetyStatus as u16)?
        // ...

… which fails on my machine:

Enter unseal key in hex (e.g. 04143672), or press enter to skip:
[ERROR] Failed to communicate with EC. Reason: "I2C Transfer not acknowledged"

I’ve ordered a new battery and will try that.

6

If we truly promote right-to-repair we should be able to unseal the battery or at least know what goes wrong without jumping through hoops. In this example, whether or not it’s a safety hazard is hidden, or “gated” behind unusual command(s).

Could be a bug on the framework-control. I got the exact same error “I2C Transfer not acknowledged”, but my battery is working normally.

For some reason when I entered the command just now it showed some “INFO” without showing me the battery status.

The problem is, since we don’t know which one has a problem, or “safety hazard”. If the mainboard’s charge controller is damaged it can brick the new battery as well.

7

If i knew the unseal key, would it be wise or not to post it here?
I am not a bms expert, so not sure how much damage someone could do to the battery if one knew it.

8

I think is likely the mainboard is causing the problem, because the battery discharged to 1% is after water reached the mainboard, and from the information OP posted, there’s no proof that the battery is damaged or is a “safety hazard”. If the battery is healthy, you can safely charge it using a power source as long as the voltage and current is below the limit. Also I think it’s a good practice for the battery to broadcast the safety status to the EC, to save all the guesswork and reducing waste caused by replacing the wrong part. One may argue that the safest thing to do is to replace the mainboard and the battery at the same time, but that is also the most wasteful, so there’s cost benefit analysis about it, and the more we know the health of the mainboard and the battery, the better in terms of decision making.

Currently, the health of the mainboard isn’t fully known since OP only posted the --smartbattery command, not the command of showing the health of the mainboard. Also, OP posted that the battery safety is “gated” behind unseal which I think is unethical since safety status should be fully known by the EC. In conclusion, replacing the battery without diagnosing the mainboard thoroughly isn’t the safest thing to do so I suggest searching for clues, either by viewing the mainboard to find any corrossion or other water damage or run some tests of the mainboard, before installing the new battery if diagnosing the battery is not desired.

9

From what is posted here, i think the fault is with the mainboard.
Batteries are pretty well sealed, so not likely to be damaged by water.
Mainboards are not well sealed, so much more likely to get damaged.

Send the mainboard to a repair shop. It is probably just a broken FET or similar.

10

However 3.2V is very low for a battery that has 3.87V nominal voltage. It’s possible that the mainboard, under the influence of water, over-discharged the battery, which may or may not trigger the undervoltage permanent fail (brick). The reason I said using a lab power supply is that if the battery is bricked it won’t charge because the BATT+ is disconnected internally (you can’t even read the voltage). If its not bricked you may save it by not letting it stay discharged, but I might be overthinking

11

I agree, but I suppose that’s the battery manufacturer’s fault, not Framework’s.

Anyways, I removed the mainboard and found corrosion on the underside near the battery connector and one of the USB ports.

PXL_20260829_185159281
PXL_20260829_1851592811920Ă—2560 1.12 MB

PXL_20260829_185203796.MP
PXL_20260829_185203796.MP1920Ă—2560 1.17 MB

12

That’s some water damage/corrosion. What’s the chip right below the “2024 -05 - 07”? It shapes like an ISL9241. If so, make sure to test and repair (if damaged) at a repair shop.

Sorry, I misread your previous posts

I skipped and didn’t notice these lines where they showes that the battery was willing to be charged, the “charger voltage” and “charger current” are direct copies of the BMS’s value. After cleaning/repairing the mainboard you can use ectool chargestate show and ectool battery to double check it

13

You mean this one? Yep, that’s the battery charger.

PXL_20260829_202535994.MP
PXL_20260829_202535994.MP1920Ă—2560 1.04 MB

14

So, it looks pretty obvious now.
There is unlikely to be anything wrong with the battery itself.
The problem is the mainboard damage.
Cleaning off the corrosion and maybe replacing a few FETs might get you going again.