Battery monitoring while "off"

Has anyone found that the management controller’s battery monitoring fails to properly track if the Reform is idle and unplugged?

I’d had the Reform turned off and disconnected from the mains for a few days. At the time it was unplugged, it was showing 100 per cent charge - and had already had an exhausted-to-full-to-exhausted charge cycle to train the management controller, which had correctly counted down from 100 to 0 per cent then powered the machine off.

I picked up the Reform a few days later and checked the management menu (Circle-B) to see how the battery was doing: 69 per cent. Fair enough, I know there’s currently a big drain from the system management controller, so I wasn’t expecting it to have maintained a full charge. I didn’t need to use it at the time, so I switched the menu off (Circle-Esc) and closed the lid.

A day later, I picked it up again and checked (Circle-B): 69 per cent still. Odd, I’d have expected it to go down again. I actually needed it this time, so I powered it on (Circle-1) and took it downstairs to do some work.

A few minutes later, the OLED started flashing a battery warning. I checked the battery status: 59 per cent, which should still be a solid two-and-a-half-hours of runtime - but still the battery warning flashed. Most cells were around 3.0V, but the top-right cell (which is obscured by the flashing warning icon, except for the digit after the point) appeared to be at 2.8V.

Disappointed, I shut the Reform down and picked up my old Dell instead.

I can’t be sure until I repeat the experiment, but it seems to me that the management controller loses track of what the batteries are doing if there isn’t any draw from the actual Reform itself - as in, each time I checked the battery status with the Reform switched off it was reading 0.00A even though the management controller, keyboard, and OLED had to be drawing some power. Over time, this seems to let the controller’s idea of how much charge is left drift away from reality - leaving you scrabbling for the charger when you thought you had a couple of hours to go.

I could be wrong, and I’ve done a full charge-discharge cycle to make sure the controller’s calibrated and once it’s recharged again will repeat the leave-it-off-for-a-few-days part to check. It’s not something you’d see if you use the thing daily, or if you always leave it connected to the mains when it’s not in use - so I’m curious, has anyone else tried leaving theirs off for a few days too?

Yes, that’s how I ended up completely draining mine:

And I almost did it a second time. I was monitoring the battery level through out the week while “off” and it was at 100% all the time. Then when I started using it the battery warning started flashing after 20min or so.

It seems better to check the voltage on the batteries and see if they start to dip under 3.2V.

1 Like

Thanks for reporting these analyses. It is entirely possible that there is a problem tracking the small amount of current that is discharged in the off state. I will look into this further.

Meanwhile, we’ve completed first versions of LPC and keyboard firmware (in tandem) that enter deep sleep modes in the off state. I’m just doing some more testing before recommending to update to these new versions.


Ooh, fantastic - looking forward to trying it!

In the meantime: the laptop’s been off for three days now. The battery monitor still says 100 per cent, 3.3V on all cells. Going to leave it another couple of days, like last time, re-check the battery monitor then fire it up and see when the warning symbol triggers.

I know it can get 5h6m of video playback from earlier testing, so I’ll set it doing that and see when it runs out.

1 Like

For the brave who want to give it a try, I have merged the Powersave/Deep Sleep features into the reform repo’s master branch: Deep Sleep/Powersave modes for Keyboard/Motherboard LPC Tandem (!20) · Merge requests · Reform / reform · GitLab

I recommend to build and flash the keyboard firmware first, and then the LPC firmware after that. Instructions:

  1. MNT Reform Handbook: Flashing the Keyboard Firmware
  2. MNT Reform Handbook: Flashing the LPC Firmware

Thank you for this!

I decided to test this out!


I built and flashed it on the MNT Reform using the following steps:

sudo apt install dfu-programmer gcc-avr avr-libc
git clone
cd reform/reform2-keyboard-fw
  • Remove the keyboard’s frame, switch the DIP switch SW84 to ON
  • Hit the reset button SW83

With an external keyboard:

su -l
cd /path/to/reform/reform2-keyboard-fw

(sudo -i ./ should probably work)
Flip back the SW84 switch, put the frame back on.


I did the following on a laptop running Arch:

sudo pacman -S gcc arm-none-eabi-gcc arm-none-eabi-newlib
git clone
cd reform/reform2-lpc-fw
make lpcrc

Then I followed the steps in the instructions. It took a bit of time to find a micro-USB cable that could also transport data :man_facepalming:. The instructions was a bit unclear that the batteries should not be unplugged. As it didn’t show up in /dev on the other computer otherwise.

When I got the virtual flash drive to show up, I simply mounted it at /mnt and ran sudo ./

sudo mount /dev/sdX /mnt
sudo ./

Where /dev/sdX was the virtual flash device (/dev/sdc in my case)

Then change back the DIP switch and hit reset.


Everything seems to be working. I now have an ON / OFF indicator in the battery status menu. Which is OFF when the laptop is powered off and ON when running. Hopefully the power drain will be a thing of the past! :smiley:


Fired the Reform up today: got the battery warning symbol at 59%, which confirms that it’s losing track of charge when off-and-unplugged.

I’ll give the firmware update a go when I get a chance - hopefully that solves the problem by reducing the "off’ power drain!

1 Like

I experienced this problem, batteries discharged completely.
@mntmn, doesn’t the BSM implement over charge/discharge protection, as specified in the battery datasheet?
I would think this protection belong in hw, not dependent on sleep/deep sleep.

I would say this is work for the LPC controller. When one cell goes below 2.5V, it could be done in two different ways:

  • the LPC should warn the iMX so that a message can be displayed to the user “you have got x minutes to connect a power source, or shutoff, otherwise you might destroy battery number y”
  • the LPC could flash a warning along the same lines on the OLED display.
    giving the failing battery number would be an interesting indication.
    And after z minutes, the LPC would force shutdown.
    Any ideas?