Active Topics

 



Notices


Reply
Thread Tools
Posts: 48 | Thanked: 39 times | Joined on Aug 2010 @ Netherlands
#1
The above message popped up in the battery applet out of the blue.
Running CSSU-thumb2, BME replacement and using the pali-recommended "modprobe -r rx51_battery".
Charging to green LED and/or rebooting does not fix it. Modprobe rx51_battery gives some numbers, but they are the wrong numbers.
Trying to recalibrate the battery with the bq27x00_battery module gives a "resource or device busy", without it the calibration script gives a read error on one of the cat commands.

Is there any way, short of reflashing, to just get this to work again?

Thanks in advance!

Last edited by LavaCroft; 2014-02-02 at 23:25.
 
Estel's Avatar
Posts: 5,029 | Thanked: 8,590 times | Joined on Mar 2011
#2
Ironically, reflashing wouldn't help, at all. I think you just had >32 charging cycles since last calibration. For some reasons, device hadn't chance to calibrate itself automaticaly (maybe you were always charging it before it reached very low level/never let it shut itself down due to out of charge?).

To fix, you need to calibrate manually:

1. Charge battery to full, until VDQ flag turns to 1
2.
Code:
modprobe -r bq27x00_battery
modprobe -r rx51_battery
3. Use your device normally, but don't shut it down, charge, or reboot. Checking battery level manually, from time to time (battery applet *won't* give you correct readings, due to modules being not loaded). Always ensure that VDQ flag is 1, otherwise, you need to start back from scratch. Accidental reboot may or may not turn VDQ to 0, depending on circumstances.

4. When voltage drops to ~3300 mV, stop whatever you're doing on device and start monitoring it closely.

5. The goal now is to get under 3248 mV and stay there for at least 15 seconds, without voltage either going above, or too much under (less than ~2900 mV), causing device to "faint" due to low power. The most reliable - although, time consuming - way is to set screen to never dim, and/or enable flashlight - so device will consume steady ammount of current. Monitor voltage and VDQ.

6. When voltage dros below threeshold (3248 mV) and stays there for 15 seconds, VDQ will immediately turn to 0 and chip recalibrate.

7. Power device off via normal way, before it "faints" - if you miss that step, it *won't* spoil calibration, but you may get your /home filesystem corrupted. You better not miss this step, or you will give yourself quite a homework (see next steps). In case of failing it, for some reason, follow step 8. Otherwise, you're finished now - start using device normally.

8. (optional, in case of missing step 7)
This step require you to run latest cssu-thumb or cssu-testing. Precisely, it require updated e2fsprogs&friends, cause Maemo's vanilla ones were ancient and segfaulted mid-way, leaving filesystem in total mess.

Boot into any recovery console (backupmenu's one, Mentalist Traceur's one, Pali's one, etc), and:
Code:
fsck /dev/mmcblk0p2 -f -p
a) If it says (amongst other things) "<filesystem name> clean" - with or without "recovering journal" before - and exits, you're good to go. Power off, and you're finished. Start using device normally.

b) If it informs about fixing some things, but exits cleanly, see point a.

c) If it ends with something like "Unexpected inconsistency, run FSCK manually", do:
Code:
fsck /dev/mmcblk0p2 -f -y -v >> /path/where/you/want/log/saved/fsck.log
Ensure, that path where you save log isn't any temporary directory (that will get nuked after boot), as you may really need that log later.

Where to save, depends on the recovery shell you're using. If you have rootfs mounted, /path/where/rootfs/is/mounted/var/log/fsck.log is a good place. Using backupmenu's root console (and *only* after mounting rootfs via 'mountroot' command), it is /tmp/mnt/rootfs/var/log/fsck.log, If I remember correctly (you can use auto-completion via TAB).

When it's finished, repeat this point (8) from the beginning, and follow approriate sub-point.

8.1. After you boot into Maemo, check fsck.log you've create in point 8 - it will contain (amongst other things), pathes to files that were repaired/salvaged (connected to lost+found) during manual fsck repair. Check every file's integrity individually. In case it "vanished", check /home/lost+found, it may be sitting there. In case of problems, determine which package missing file depend to, and reinstall whole package.
---

Appendix:
To check VDQ flag and voltage conveniently, either use bq27200.sh script, or package BNF (the latter is my favorite method, but no surprise here, as I've created it ).

Appendinx 2:
Don't get scared by ammount of text here - I tried to explain everything in details, and half of this (as it turned to be) tutorial is an emergency kit for worst-case scenario of filesystem corruption, due to device fainting of low power. By being at least basically aware of situation, you won't hit it, saving yourself half of this

Cheers,
/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following 4 Users Say Thank You to Estel For This Useful Post:
Posts: 48 | Thanked: 39 times | Joined on Aug 2010 @ Netherlands
#3
Thanks for the excellent reply. I will let you know how it works out.

[EDIT] Can I trust the N900 to actually stop charging once the battery is full? Might be a silly questions, but I'm slightly concerned about it.

Last edited by LavaCroft; 2014-02-02 at 18:31.
 

The Following User Says Thank You to LavaCroft For This Useful Post:
pichlo's Avatar
Posts: 4,934 | Thanked: 14,765 times | Joined on Sep 2012 @ UK
#4
Originally Posted by LavaCroft View Post
Can I trust the N900 to actually stop charging once the battery is full?
Yes. (10 chars)
__________________
In particle accelerators atoms are indeed not only touching each others. But banging together in a massive explosive orgasm.
-- nieldk in a TMO post
 

The Following 2 Users Say Thank You to pichlo For This Useful Post:
Posts: 48 | Thanked: 39 times | Joined on Aug 2010 @ Netherlands
#5
The process seems to have worked. Thanks a lot.

About your hunches as to why it happened, both the >32 recharge cycles and the 'always charging' ideas were correct. I will have to keep this in mind for the future.
 

The Following User Says Thank You to LavaCroft For This Useful Post:
Estel's Avatar
Posts: 5,029 | Thanked: 8,590 times | Joined on Mar 2011
#6
I' glad it have worked for you As for >32 cycles, yea - it is good idea to let it, from time to time (like, once or twice in month) - discharge 'till shutdown, so it will update it's calibration data, and won't hit threeshold anytime soon.

Of course, it only makes sense if VDQ is 1 during that discharge (when battery is low and you think "heck, I could let it discharge now", just check if VDQ is still 1), otherwise it won't recalibrate. Just be sure to not have any unnecessary applications running, when expecting to let it shutdown itself. Standard Maemo stuff is OK, doesn't need to deliberately kill things from terminal.

Obviously, by "discharge and shutdown", I mean doing so with bq27x00_battery and rx51_battery modules *loaded*, so it will shutdown safe way, just after recalibrating - *not* letting it fade out due to low power at ~2900 mV, with modules unloaded (otherwise, points 8+ from previous post, aka "filesystem corruption", apply ).

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!

Last edited by Estel; 2014-02-03 at 05:41.
 

The Following 3 Users Say Thank You to Estel For This Useful Post:
Posts: 10 | Thanked: 8 times | Joined on Aug 2017
#7
Originally Posted by Estel View Post
Ironically, reflashing wouldn't help, at all. I think you just had >32 charging cycles since last calibration. For some reasons, device hadn't chance to calibrate itself automaticaly (maybe you were always charging it before it reached very low level/never let it shut itself down due to out of charge?).

To fix, you need to calibrate manually:

1. Charge battery to full, until VDQ flag turns to 1
2.
Code:
modprobe -r bq27x00_battery
modprobe -r rx51_battery
3. Use your device normally, but don't shut it down, charge, or reboot. Checking battery level manually, from time to time (battery applet *won't* give you correct readings, due to modules being not loaded). Always ensure that VDQ flag is 1, otherwise, you need to start back from scratch. Accidental reboot may or may not turn VDQ to 0, depending on circumstances.

4. When voltage drops to ~3300 mV, stop whatever you're doing on device and start monitoring it closely.

5. The goal now is to get under 3248 mV and stay there for at least 15 seconds, without voltage either going above, or too much under (less than ~2900 mV), causing device to "faint" due to low power. The most reliable - although, time consuming - way is to set screen to never dim, and/or enable flashlight - so device will consume steady ammount of current. Monitor voltage and VDQ.

6. When voltage dros below threeshold (3248 mV) and stays there for 15 seconds, VDQ will immediately turn to 0 and chip recalibrate.

7. Power device off via normal way, before it "faints" - if you miss that step, it *won't* spoil calibration, but you may get your /home filesystem corrupted. You better not miss this step, or you will give yourself quite a homework (see next steps). In case of failing it, for some reason, follow step 8. Otherwise, you're finished now - start using device normally.

8. (optional, in case of missing step 7)
This step require you to run latest cssu-thumb or cssu-testing. Precisely, it require updated e2fsprogs&friends, cause Maemo's vanilla ones were ancient and segfaulted mid-way, leaving filesystem in total mess.

Boot into any recovery console (backupmenu's one, Mentalist Traceur's one, Pali's one, etc), and:
Code:
fsck /dev/mmcblk0p2 -f -p
a) If it says (amongst other things) "<filesystem name> clean" - with or without "recovering journal" before - and exits, you're good to go. Power off, and you're finished. Start using device normally.

b) If it informs about fixing some things, but exits cleanly, see point a.

c) If it ends with something like "Unexpected inconsistency, run FSCK manually", do:
Code:
fsck /dev/mmcblk0p2 -f -y -v >> /path/where/you/want/log/saved/fsck.log
Ensure, that path where you save log isn't any temporary directory (that will get nuked after boot), as you may really need that log later.

Where to save, depends on the recovery shell you're using. If you have rootfs mounted, /path/where/rootfs/is/mounted/var/log/fsck.log is a good place. Using backupmenu's root console (and *only* after mounting rootfs via 'mountroot' command), it is /tmp/mnt/rootfs/var/log/fsck.log, If I remember correctly (you can use auto-completion via TAB).

When it's finished, repeat this point (8) from the beginning, and follow approriate sub-point.

8.1. After you boot into Maemo, check fsck.log you've create in point 8 - it will contain (amongst other things), pathes to files that were repaired/salvaged (connected to lost+found) during manual fsck repair. Check every file's integrity individually. In case it "vanished", check /home/lost+found, it may be sitting there. In case of problems, determine which package missing file depend to, and reinstall whole package.
---

Appendix:
To check VDQ flag and voltage conveniently, either use bq27200.sh script, or package BNF (the latter is my favorite method, but no surprise here, as I've created it ).

Appendinx 2:
Don't get scared by ammount of text here - I tried to explain everything in details, and half of this (as it turned to be) tutorial is an emergency kit for worst-case scenario of filesystem corruption, due to device fainting of low power. By being at least basically aware of situation, you won't hit it, saving yourself half of this

Cheers,
/Estel
I've tried this method, but before 3248mV my phone will auto-shutdown. Did it means that modprobe -r doesn't work ? Or something else in the system did auto shutdown to prevent corruption?

My battery only detected as 13xxmAH but actually it 2000mAh.
Please help
 
Reply

Tags
battery, bme replacement, cssu thumb2

Thread Tools

 
Forum Jump


All times are GMT. The time now is 09:39.