Battery voltage jumps

Hi,

I (think) am having battery problems on my pocket which may explain spontaneous reboots when running on battery power. The random reboots seem to happen especially when starting some heavyish app like firefox or (dis)connecting usb power cable. When this happens the display gets some random horizontal stripes, dims and, after one or two seconds, reboots.

This has been happening for months now but I did not have any hint what was wrong so did not know how to describe what was happening.. But today I noticed the battery status going from 100% to 0% a couple of times while connected to power and found the following using dmesg:

[  308.504861] get_bat_property: Voltage jump from 8399000 to 0
[  308.504870] get_bat_property: Clamping to 7399000
[  314.500758] get_bat_property: Voltage jump from 8362000 to 0
[  314.500769] get_bat_property: Clamping to 7362000
[  316.520668] get_bat_property: Voltage jump from 7362000 to 8399000
[  316.520677] get_bat_property: Clamping to 8362000
[  320.740761] get_bat_property: Voltage jump from 8399000 to 0
[  320.740771] get_bat_property: Clamping to 7399000
[  336.524489] get_bat_property: Voltage jump from 8399000 to 0
[  336.524498] get_bat_property: Clamping to 7399000
[  470.675320] get_bat_property: Voltage jump from 8350000 to 0
[  470.675331] get_bat_property: Clamping to 7350000

What is wrong here? How do I debug and fix this?

Btw, I am on the 20250429 firmware.

Edit: I disconnected and reconnected the batteries but still seeming the jump messages appear. Also the charger board looks fine.
Edit2: The problem is worse with RK3588 compared to with the original i.MX8M+, probably because it pulls more power?

Remco

I have these too.

Upower is who decides to shutdown the computer when it thinks battery is at 0%. Until this is solved you can uninstall upower package to avoid the shutdown.

I don’t have the upower package installed so it seems the crash/reboot is triggered by an actually power dip.

This is a bug in the communication between lpc_reform and the sysctl firmware. Somebody needs to debug it.

1 Like

Can I help with this? I have no technical knowledge on this matters, but a Pocket, a serial-to-usb adapter and linux command line fluency if that helps.

I haven’t really looked at the Linux ↔ sysctl SPI interface yet. Here are some pointers:

reform_lpc2 kernel driver sources are here: lpc · main · Reform / MNT Reform Tools · GitLab

Firmware sources: pocket-reform-sysctl-fw · main · Reform / MNT Pocket Reform · GitLab

Debug output from reform_lpc2 can be seen in dmesg. sysctl firmware dumps debug output to /dev/ttyACM0.

My general idea was to replace the SPI interface with a USB HID interface, but I haven’t actually done anything about that so far.

Thank you very much for the pointers. Personally I have no skills to modify or read this code, but if anytime somebody takes a look at this please ping me, I’m willing to do any testing needed.

I experienced the same issue.
To diagnose this, I wrote a small tool which interact with sysfw through spidev.
And confirmed that, as mentioned in this thread, responses from sysfw are sometimes get corrupted.
I’m trying to prevent this by adjusting intervals between spi_read/spi_write, but if it does not work, we need to implement some kind of error recovery logic in the lpc driver.

I’ve created several patches for sysctl-fw and reform2_lpc to fix this.
Now waiting for account approval of source.mnt.re…

3 Likes

I’m occasionally seeing the battery percentage jump to 0% (in the waybar widget) and then shortly after return to the actual value. Could this be related?

Yes, that is exactly what I fixed.

But wait, that behaviour should have been workarounded by this commit six months ago.
Perhaps you haven’t upgraded your kernel in a while?

I run an apt upgrade almost every day so my kernel should be very recent

Hmm, then your problem may not be related. Sorry.

Hmm, confusing. I’m also on a regular apt upgrade diet so I am curious what you fixed.

Also, I’m having random reboots which I am assuming are related to the voltage jumps I’m seeing in dmesg output. Can’t see them in the systemd journal after reboot but I guess the machine just did not have time to write these lines to disk. These reboots can be unrelated, of course.

Just to be sure, have you read this?
If your dmesg says ‘voltage jump to 0’, probably it is not really the voltage changing, but the failure to receive data from the sysfw.
My patch is to fix such a read failure.

Yes, I’ve seen that and I do not have upower on my system. I do look forward to your changes so I can rule out power drops, maybe.

1 Like

If it should take longer for your account to get approved, I could also offer that you mail me your patches in git-format-patch format to josch@debian.org and I can file MRs with your commits, preserving your authorship information.

Your reform2_lpc changes I can apply directly as I maintain reform-tools.

1 Like