[Solved] - 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.

15

Update: I tried a good battery and observed almost the same behaviour.
Only difference: the old battery had repeated connect attempts and disconnects in the console log, which the new one didn’t. I suppose this was either caused by deep discharge or a BMS lock.

Took my laptop to a repair shop that knows about framework laptops. They said they recommend getting a new mainboard, so that’s what I ended up doing.

16

They didn’t even try to repair it? That’s a bit unfortunate

17

Not all repair shops are setup to do low level repairs other than basic surface mount fixes.

They may have determined the water damage could have damaged traces too or just not have been willing to work on it and then stand behind it if something was to fail again.

It is a different story if a component fails on its own vs. water damage that can be much more widespread.

Some shops would take the risks while others would just let the customer know what they have found and let them decide.

Sample sizes of Framework mainboard repairs are still miniscule compared to most other laptop brands for now.

Like I have said before there is probably an opportunity for someone to promote diagnostic and repair of just Framework boards as an independent shop here on the forums and those of us without a decent local repair shop nearby would be willing to mail the boards in for diagnostic/repair. This case might be a good example of an effort to try and fix it but there is not always a guarantee that a $300-$500 fix (after taxes and shipping) is a good investment vs a new board with a warranty.

18

Well, given that we can read the registers from the charge controller chip, I would assume the charger chip itself was ok.
From the EC, you can even tell if power is reaching the charger chip from the USB-C.
You also reported that power from the USB-C is reaching the CPU as the mainboard works, it just does not charge the battery.
Based on that knowledge, I would have cleaned the board and then swapped out the FET that is closest to the battery in the circuit diagram.
It would have been quite quick to do, and not cost a lot.
If it failed to fix the problem, I would probably have given up at that point, because it could be a much wider amount of failed components then.
But, if it was my mainboard, and I had a schematic and board view documents, I would have just carried on until I fixed it. Mainly out of curiosity than costs.

Maybe you could go to the repair shop again, and ask them for the cost to clean the PCB and swap out the FET. Then based on the cost, you could decide. It might or might not fix the problem. Once removed, it is really easy to test if the FET has failed or not.

19

First, clean the board using isopropyl alcohol

isl9241_0
isl9241_0800Ă—375 7.15 KB

Since the laptop is working on AC, I would assume the BYPSG is working and the buck boost is working so I suggest replacing the BGATE and possibly NGATE. If it still doesn’t work, replace the Q1 to Q4, if not working still, replace the controller chip(but I don’t think it’s a problem and I would probably give up). If it’s fixed try connecting to the new battery first. If working, connect to the old battery. If mainboard replacement is required, install an RTC battery, find a way to bypass the battery and fan detection so you can use a custom cooler plugged in only

The user doesn’t need to unseal (or find out which information is behind unseal) to know whether the battery is bricked. There are two pieces of information. One is the chg_current or Desired current, it should normally only be zero when full, if zero when empty, it’s bricked. The other is the alert message TDA (Terminate Discharge Alarm), TCA (Terminate Charge Alarm), if both are active at the same time, the battery is bricked. OP’s battery isn’t bricked, but if the mainboard fault causes current leakage it could brick the battery by over discharging it.

Does the shop who knows framework lend you a mainboard so you can charge the battery to 50% (or at least find out whether the discharged battery is bricked so you can get rid of it earlier)

20

Hi,

I think the user reported the laptop still working while it was trying to charge the battery, but failed to charge the battery.
If that is the case, the only component that could have failed would be the BGATE FET. I.e. the one closest to the battery.
If any of the other components had failed, the laptop CPU would not be getting any power.

Thus my suggestion to go back to the repair shop and ask them to clean the board and then try replacing the BGATE FET.

On the other hand, if that same repair shop did not spot this potential quick fix by looking at the circuit diagram, maybe don’t trust them, and try a different repair shop.