Battery stopped charging

starter · August 21, 2026, 5:29pm

After updates, the battery charge only decreases.

starter · August 21, 2026, 5:33pm

I downgrade the firmware version, the battery was charging but very weakly, and then the system stopped booting, so I reverted to the latest version.

NeonkAaa · August 22, 2026, 4:36pm

For me I had this for 1-2 months now. Sometimes when then charge drops below 40% (and especially 25%), there is chance it will arrive to the loop: “charge for 15-30 seconds, then keep the amperes at around 0 no matter the load”. And the batteries are a bit disbalanced during this activity, the last time it was 3.8 and 4.1 V. It helps either to discharge to 0 and then charge back, or to re-plug every 30 seconds.

Anyway, it seems to be stable once it becomes more than 3.9-4.0 V.

starter · August 23, 2026, 9:33am

I’m afraid if I drain it to nothing, there won’t be enough power to turn it on. I have only two options: buy the latest version of the charging board or wait for a fix.

NeonkAaa · August 23, 2026, 9:54am

Then it worth mentioning it is for the Board v2.

starter · August 23, 2026, 10:02am

The date on my board is 2023.)

chorc · August 26, 2026, 6:29pm

I recently had to use a macbook charger (the bigger one) and seen this exact behavior, it charges for few seconds and then stops charging completely. I think this is new, because I recall charging from a macbook charger last winter and it was working. Normally I charge my Pocket with some ugreen charger, and the standard steam deck charger (both not as powerful as that macbook charger) - those are working fine even today, I can see Pocket getting around 1A rock solid, both cells are at 4.1v.

starter · August 29, 2026, 11:06am

I discharged the battery to zero, then connected it, but the charge percentage remains zero. Use device is only possible when connected to a power supply.

minute · August 29, 2026, 11:35am

Your charger board is slightly damaged, the thermistor th2 is knocked off, which could explain this behavior. I didn’t spot this at first when looking at your post a few days ago.

Could you kindly complete the process from this step on MNT Support

After completing the last step we’ll send you a free replacement charger module V2.0. You can also include a link to this thread here.

minute · August 29, 2026, 11:35am

BTW if the cells discharge, you can use the bypass technique explained in that support process to use the Pocket Reform without batteries for a while, for example with a powerbank, until you get your new charger board.

Nebula-System · August 29, 2026, 1:33pm

came on the forums to search for this issue and came here.

i also have a board with a 2023 date in mine, i’ve run into this intermittently since ~3 months after i upgraded my batteries. i did run the typical discharge then recharge cycles to calibrate things when i got them, but i notice that anytime i put the Pocket Reform on charge when it’s anywhere over ~20% charged, this issue follows where it just tries to retain 0A, and i find it at virtually the same % after leaving it plugged in overnight (which gets rather annoying). i find it happens more consistently the higher the charge when i plug it in, and if i plug it in when it’s over ~80% it sometimes slowly discharges. is this fixed in board V2? should i follow the same test steps linked?

minute · August 30, 2026, 11:18pm

Is your charger board physically OK? (No knocked off components)
Can you record some logs from tio /dev/ttyACM0 when you plug in the USB-C power supply and it’s not charging like expected, and post here? Doesn’t have to be a lot, just to see if the PD negotiation works and what happens shortly after.

Nebula-System · August 30, 2026, 11:31pm

1: yes it is

2: can and will do, gimme a few days to make sure i catch the behaviour I usually see

Nebula-System · September 2, 2026, 7:56pm

ok so here’s the logs i got. the annoying part is they don’t seem any different but the behaviour is very different. first up is what it says when it works normally, and charges at -1.6a to -2.4a:

nebula@The-Reform-False-God-Of-The-Abyss-Entropys-Paradox-Conqueror-Of:~$ tio /dev/ttyACM0
[21:04:06.769] tio 3.9
[21:04:06.769] Press ctrl-t q to quit
[21:04:06.770] Connected to /dev/ttyACM0
# [pd] PD_STATE_UNATTACHED -> SNK CC2, going to PD_STATE_UNATTACHED_SNK
# [pd] PD_STATE_UNATTACHED_SNK VBUS is now OK
# [pd] handle_msg_from_power_source: hdr: 0x000071a1 their datarole: DFP our datarole: UFP
# [pd]   pd_src_fixed_pdo#1: V=5.00 Imax=3.00 unconstrained
# [pd]   pd_src_fixed_pdo#2: V=9.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#3: V=12.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#4: V=15.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#5: V=20.00 Imax=3.25
# [pd]   not a fixed PDO: 0xc8dc3264
# [pd]   not a fixed PDO: 0xc9903241
# [pd]   requesting PDO 5, 20 V (max 3250 mA) at 3000 mA
# [pd] handle_msg_from_power_source: hdr: 0x00000161 their datarole: DFP our datarole: UFP
# [pd]   supply sent goodcrc.
# [pd] handle_msg_from_power_source: hdr: 0x00000363 their datarole: DFP our datarole: UFP
# [pd]   supply accepted our requested PDO.
# [pd] handle_msg_from_power_source: hdr: 0x00000566 their datarole: DFP our datarole: UFP
# [pd]   power supply ready.
# [charger] setting limit 60 
# [kbd<] 41 41 00 00 00 00 00 00 mA-2147mV08280  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2137mV08277  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2136mV08277  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2145mV08277  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2113mV08274  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2113mV08274  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2119mV08274  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2089mV08276  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2092mV08276  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2109mV08263  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2087mV08263  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2085mV08263  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2021mV08281  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2013mV08281  33% P1

# [kbd<] 41 41 00 00 00 00 00 00 mA-2045mV08281  33% P1

next up is the first time i caught it behaving oddly when it was only charging at about -0.6a:

nebula@The-Reform-False-God-Of-The-Abyss-Entropys-Paradox-Conqueror-Of:~$ tio /dev/ttyACM0
[01:22:38.612] tio 3.9
[01:22:38.612] Press ctrl-t q to quit
[01:22:38.613] Connected to /dev/ttyACM0
# [pd] PD_STATE_UNATTACHED -> SNK CC1, going to PD_STATE_UNATTACHED_SNK
# [pd] PD_STATE_UNATTACHED_SNK VBUS is now OK
# [pd] handle_msg_from_power_source: hdr: 0x000071a1 their datarole: DFP our datarole: UFP
# [pd]   pd_src_fixed_pdo#1: V=5.00 Imax=3.00 unconstrained
# [pd]   pd_src_fixed_pdo#2: V=9.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#3: V=12.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#4: V=15.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#5: V=20.00 Imax=3.25
# [pd]   not a fixed PDO: 0xc8dc3264
# [pd]   not a fixed PDO: 0xc9903241
# [pd]   requesting PDO 5, 20 V (max 3250 mA) at 3000 mA
# [pd] handle_msg_from_power_source: hdr: 0x00000161 their datarole: DFP our datarole: UFP
# [pd]   supply sent goodcrc.
# [pd] handle_msg_from_power_source: hdr: 0x00000363 their datarole: DFP our datarole: UFP
# [pd]   supply accepted our requested PDO.
# [pd] handle_msg_from_power_source: hdr: 0x00000566 their datarole: DFP our datarole: UFP
# [pd]   power supply ready.
# [charger] setting limit 60 
# [kbd<] 42 41 00 00 00 00 00 00 mA-0674mV08378  74% P1

# [kbd<] 42 41 00 00 00 00 00 00 mA-0688mV08378  74% P1

# [kbd<] 42 41 00 00 00 00 00 00 mA-0674mV08378  74% P1

# [kbd<] 42 41 00 00 00 00 00 00 mA-0657mV08368  74% P1

# [kbd<] 42 41 00 00 00 00 00 00 mA-0662mV08368  74% P1

# [kbd<] 42 41 00 00 00 00 00 00 mA-0658mV08368  74% P1

# [kbd<] 42 41 00 00 00 00 00 00 mA-0663mV08372  74% P1

# [kbd<] 42 41 00 00 00 00 00 00 mA-0617mV08372  74% P1

# [kbd<] 42 41 00 00 00 00 00 00 mA-0622mV08372  74% P1

# [kbd<] 42 41 00 00 00 00 00 00 mA-0633mV08372  74% P1

and the latest instance where i caught it charging at only -0.3ma to -0.4ma.

nebula@The-Reform-False-God-Of-The-Abyss-Entropys-Paradox-Conqueror-Of:~$ tio /dev/ttyACM0
[09:48:47.960] tio 3.9
[09:48:47.960] Press ctrl-t q to quit
[09:48:47.971] Connected to /dev/ttyACM0
# [pd] PD_STATE_UNATTACHED -> SNK CC2, going to PD_STATE_UNATTACHED_SNK
# [pd] PD_STATE_UNATTACHED_SNK VBUS is now OK
# [pd] handle_msg_from_power_source: hdr: 0x000071a1 their datarole: DFP our datarole: UFP
# [pd]   pd_src_fixed_pdo#1: V=5.00 Imax=3.00 unconstrained
# [pd]   pd_src_fixed_pdo#2: V=9.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#3: V=12.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#4: V=15.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#5: V=20.00 Imax=3.25
# [pd]   not a fixed PDO: 0xc8dc3264
# [pd]   not a fixed PDO: 0xc9903241
# [pd]   requesting PDO 5, 20 V (max 3250 mA) at 3000 mA
# [pd] handle_msg_from_power_source: hdr: 0x00000161 their datarole: DFP our datarole: UFP
# [pd]   supply sent goodcrc.
# [pd] handle_msg_from_power_source: hdr: 0x00000363 their datarole: DFP our datarole: UFP
# [pd]   supply accepted our requested PDO.
# [pd] handle_msg_from_power_source: hdr: 0x00000566 their datarole: DFP our datarole: UFP
# [pd]   power supply ready.
# [charger] setting limit 60 
# [kbd<] 41 42 00 00 00 00 00 00 mA-0392mV08388  93% P1

# [kbd<] 41 42 00 00 00 00 00 00 mA-0392mV08382  93% P1

# [kbd<] 41 42 00 00 00 00 00 00 mA-0404mV08382  93% P1

# [kbd<] 41 42 00 00 00 00 00 00 mA-0382mV08382  93% P1

# [kbd<] 41 42 00 00 00 00 00 00 mA-0395mV08385  93% P1

now this seems like it could be a safety feature, but it works poorly if so since after fully charging, the device still drains when this happens, resulting in a slow trickle of drain. since i plug it in to recharge when i do (sleep) it can end up being under 60% by morning sometimes. it’s like the device can’t run off the charger without touching the batteries, like maybe the BMS doesn’t have a bypass to make it run off charger and then switch back when unplugged? if so i can submit a hardware improvement request unless board V2 fixes this, but maybe it’s not that.

for context on the test environment: the device was in the exact same state when plugged in for all three, so the charger was not just being maxed out due to load being higher and thus, less headroom to actually charge with, and those extra lines afterward appeared when i hit Hyper+Enter b to check charge rates.

Nebula-System · September 3, 2026, 1:46pm

ok last night it acted up again, unfortunately i didn’t get logs. i think i’ll leave a terminal open to tio in the background a while to ensure i get those logs.

one thing i did notice is one cell is slightly disbalanced, 3.6-3.7 volts instead of 3.8 like the other one. bad cell maybe? should i replace it/both? how do i put them into balance? i thought the BMS would keep them in balance once i did the full charge to full discharge cycles a few times like i did when i got them but it seems they may have drifted.

chorc · September 4, 2026, 7:53am

I’m balancing cells by removing them from the Pocket and charging them individually to the max. It was needed slightly more often with v1 charging board, with v2 I think I’ve done it just once as a habit.

Nebula-System · September 5, 2026, 4:04pm

GOT IT, here’s the logs from last night. woke up to it at 37% this morning.

nebula@The-Reform-False-God-Of-The-Abyss-Entropys-Paradox-Conqueror-Of:~$ tio /dev/ttyACM0
[20:11:29.957] tio 3.9
[20:11:29.957] Press ctrl-t q to quit
[20:11:29.958] Connected to /dev/ttyACM0
# [kbd<] (err stxc)
# [kbd<] (err stxc)
# cli err 1668838515
# [kbd<] (err stxc)
# [kbd<] (err stxc)
# cli err 1668838515
# [kbd<] (err stxc)
# cli err 1668838515
# [pd] PD_STATE_UNATTACHED -> SNK CC1, going to PD_STATE_UNATTACHED_SNK
# [pd] PD_STATE_UNATTACHED_SNK VBUS is now OK
# [pd] handle_msg_from_power_source: hdr: 0x000071a1 their datarole: DFP our datarole: UFP
# [pd]   pd_src_fixed_pdo#1: V=5.00 Imax=3.00 unconstrained
# [pd]   pd_src_fixed_pdo#2: V=9.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#3: V=12.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#4: V=15.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#5: V=20.00 Imax=3.25
# [pd]   not a fixed PDO: 0xc8dc3264
# [pd]   not a fixed PDO: 0xc9903241
# [pd]   requesting PDO 5, 20 V (max 3250 mA) at 3000 mA
# [pd] handle_msg_from_power_source: hdr: 0x00000161 their datarole: DFP our datarole: UFP
# [pd]   supply sent goodcrc.
# [pd] handle_msg_from_power_source: hdr: 0x00000363 their datarole: DFP our datarole: UFP
# [pd]   supply accepted our requested PDO.
# [pd] handle_msg_from_power_source: hdr: 0x00000566 their datarole: DFP our datarole: UFP
# [pd]   power supply ready.
# [charger] setting limit 60 
# [pd] PD_STATE_ATTACHED_SNK VBUS went away
# [pd] PD_STATE_SETUP
# [pd] PD_STATE_SETUP done, going to PD_STATE_UNATTACHED
# [kbd<] (err stxc)
# cli err 1668838515
# [action] turn_som_power_on
# [spi] init_spi_client done
# [action] turn_som_power_on
# [spi] init_spi_client done
# [kbd<] (err stxc)
# cli err 1668838515
# [kbd<] 34 37 00 00 00 00 00 00 mA 0976mV07239  41% P1

# [kbd<] 34 37 00 00 00 00 00 00 mA 0976mV07239  41% P1

# [pd] PD_STATE_UNATTACHED -> SNK CC1, going to PD_STATE_UNATTACHED_SNK
# [pd] PD_STATE_UNATTACHED_SNK VBUS is now OK
# [pd] handle_msg_from_power_source: hdr: 0x000071a1 their datarole: DFP our datarole: UFP
# [pd]   pd_src_fixed_pdo#1: V=5.00 Imax=3.00 unconstrained
# [pd]   pd_src_fixed_pdo#2: V=9.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#3: V=12.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#4: V=15.00 Imax=3.00
# [pd]   pd_src_fixed_pdo#5: V=20.00 Imax=3.25
# [pd]   not a fixed PDO: 0xc8dc3264
# [pd]   not a fixed PDO: 0xc9903241
# [pd]   requesting PDO 5, 20 V (max 3250 mA) at 3000 mA
# [pd] handle_msg_from_power_source: hdr: 0x00000161 their datarole: DFP our datarole: UFP
# [pd]   supply sent goodcrc.
# [pd] handle_msg_from_power_source: hdr: 0x00000363 their datarole: DFP our datarole: UFP
# [pd]   supply accepted our requested PDO.
# [pd] handle_msg_from_power_source: hdr: 0x00000566 their datarole: DFP our datarole: UFP
# [pd]   power supply ready.
# [charger] setting limit 60 
# [pd] PD_STATE_ATTACHED_SNK VBUS went away
# [pd] PD_STATE_SETUP
# [pd] PD_STATE_SETUP done, going to PD_STATE_UNATTACHED
# [kbd<] (err stxc)
# cli err 1668838515

starter · September 8, 2026, 9:46pm

The power controller arrived for replacement. The laptop works, but it doesn’t charge and the update option has disappeared in gnome-firmware.

sudo fwupdmgr update
WARNING: UEFI ESP partition not detected or configured
See PluginFlag:esp not found · fwupd/fwupd Wiki · GitHub for more information.
Devices with the latest available firmware version:
• Pocket Reform Input 2.0
• Pocket Reform System Controller 2.0

lislegaard · September 9, 2026, 9:11am

Hey I just wanted to chime in here as well. I have been using the charger that came with my Macbook pro 13 m1 to charge my Pocket Reform (3588, charger b oard v2, ordered december 2025) without problems.

I recently did the firmware update.

A few days ago I charged my Pocket for a few hours while it was powered on, only to come back and see that it was only at 14%. Checking the oled I could see that the voltage was going 0, -0,2, -0,35, -0,8, -1, 0, -0,2, .0,35, .0,8, -1, 0, (something like that.) maybe a bit higher but it would always drop down to 0. Like a loop getting a bit of charge and then giving up.

I tried with a different non-Apple USB-C brick and it worked perfectly. Constant - charge and a good number.

chorc · September 9, 2026, 11:34am

This looks like a behavior I’ve reported above. Since that time I was able to try with another macbook charger, and it also fails in the similar way. This is how it looks externally.

output