Originally Posted by jvollmann

Also tried with: modprobe bq27x00_battery, the results were all 0 but the voltage, current, temp and design:

cat /sys/class/power_supply/bq27200-0/capacity
0
cat /sys/class/power_supply/bq27200-0/charge_full
0
cat /sys/class/power_supply/bq27200-0/charge_now
0
cat /sys/class/power_supply/bq27200-0/time_to_empty_avg
0
cat /sys/class/power_supply/bq27200-0/time_to_empty_now
0
cat /sys/class/power_supply/bq27200-0/time_to_full_now
0


cat /sys/class/power_supply/bq27200-0/charge_full_design
2056320

Originally Posted by Estel

Just little addition to what Mentalist said - AFAIK device hanging totally instead of rebooting has one disadvantage - possible filesystem corruptions. Watchdogs tends to unmount filesystem before rebooting, just like bme does (#fixme if I'm wrong).
.

Originally Posted by Estel

Anyway, especially this line:

cat /sys/class/power_supply/bq27200-0/charge_full_design
0

...makes me wonder, if Your ID pin of battery is even connected/recognized? That could be source of problems, BUT - (another AFAIK) bme turns device on in < 1 second when unable to probe ID pin. I never heard that R&D mode disables this behavior - can someone running on R&D confirm/deny this?

And, wasn't temperature also probed on ID pin?

Originally Posted by Estel

It's VERY strange all together. could other people, reporting there "same issues" do similar cat probing? I think first of all, we need to check if it's "reproduceable" problem, that may hit some devices, or jvollmann's troubles are unique, and other doesn't share same symptoms.

From top of my head i would still say "damaged bq_27200 chip", but somehow voltage and temp is probed correctly... Huge WTF.

Originally Posted by Estel

Not for sure. Info you get from bq_27200 module is read-only data, independent from bme (battery monitor entity), which MAY or MAY NOT think the same - unfortunately, AFAIK we can't check this, thank to Nokia closed source bme (curse them 1000 times for that, for MANY reasons).

So, ID PIN is definitely probed correctly. Ho ever, at least bq_module think, that battery capacity at full charge is still 0 - this may be symptom of problem, but may also mean that bq module haven't had a chance to perform internal calibration of values (which shouldn't cause the problem on itself).
[...]

I think You could try 2 things, independent from each other:
[...]
Doing that, we at least check it all bq_27200 reports can be correct - this way, it's most unlikely that bq_27200 chip is damaged. Still, nothing sure for 100%, but at least we can filter out one possible symptom.

Originally Posted by jvollmann

.
getbootstate: Unknown battery detected. raw bsi value 240
getbootstate: Entering state 'SHUTDOWN'
getbootstate: slide open, attemptin to use bootmenu
getbootstate: Unknown battery detected. raw bsi value 241

Originally Posted by joerg_rw

ok, now that I'm at end of this thread, it seems you managed to spot the root cause. :-) Congrats. It's quite obvious this can only be a hw defect. Does anybody know what's a "good" value for BSI? (I probably could look up in source of getbootstate, but bear with me...)

jvollmann, please check carefully your 3 contact blades of battery contact in device - CLEAN them!

BSI also gets probed by modem directly, so I wonder what modem says to this. Alas we can't ask the modem ;-)

I only hope this isn't a silicon burnout, possibly caused by overclocking or harsh treatment of device like attaching alien power to battery contacts

cheers
jOERG

About Estel's getbootstate.c:
- I installed gcc in n900 but i can't compile the file. Too many errors while compiling. I will try with SDK later!
- If it works, do you think this will let me charge the battery?

Originally Posted by Estel

Hey joerg_rw! Thanks for coming here to help us. Common sense also tell me that it's possible only by some hw effect, but for some reason, it doesn't seem right for me. You're perfectly right that many things said there were just assumptions - that's why lot of #fixme - but especially two things doesn't fit IMO for hardware fail theory. First, jvollmann find posts from other users having same issues - they claimed that Nokia Care solved it flashing via serial pins beneath battery. Still I don't buy it as-is, cause I see no reasons why unprotected D+/D- pins could result in "deeper" reflash, but...

Then, despite fact You've suggested to scratch totally one of my posts (and I'm sure You're right about that - just to avoid misunderstanding), I think You'll agree that further update by jvollmann about his typo in command, resulting in false "0" for "charge_full_design", thus leaving only:

cat /sys/class/power_supply/bq27200-0/capacity
0
cat /sys/class/power_supply/bq27200-0/charge_full
0
cat /sys/class/power_supply/bq27200-0/charge_now
0
cat /sys/class/power_supply/bq27200-0/time_to_empty_avg
0
cat /sys/class/power_supply/bq27200-0/time_to_empty_now
0
cat /sys/class/power_supply/bq27200-0/time_to_full_now
0

Originally Posted by Estel

...as 0 may root from chip's inability to perform ANY calibration (as per 412b and shadowjk's posts, it's performed internally no matter if You use stock kernel or power-kernel), cause jvollmann isn't able to charge via USB cable (only charging battery externally). Mix it with many full reflash procedures - including cold reflash and EMMC reflash (yea, not quite relevant, but You know what i mean), and this may be why capacity, charge_full, charge_now, both "times to empty" and "time to full" are 0's.

Then, charge_full_design shown as "2056320" , which is calculated by measuring resistance between ID pin and ground (thus being totally wrong, by the way), mean that ID pin IS probed correctly, right?

Originally Posted by Estel

---

As for Your question, correct values for BSI are:

32-85 - Service battery, result in "LOCAL" bootstate
87-176 - Test battery, result in "TEST" bootstate
280-568 - Normal battery, no bootstate change, continue checking.

Everything else - "UNKNOWN" and shutdown, except R&D mode.

While 28-568 result in our perfectly fine load, I have no idea how LOCAL or TEST bootstates affect booting. It seems that scripts in /sbin/preinit/ and /etc/ that call getbootstate decide what to do - they're open, so probably, we can check that

Originally Posted by Estel

1. That's why I told You about SDK/scartchbox - many "include" at the beginning, which You probably don't have with only gcc.

2. IF it works, You'll definitely be able to charge battery - it return exact same state as NORMAL (280-568), so no reasons why Your battery should be threaten differently. Charging with "UNKNOWN" doesn't work in R&D, cause Nokians use "dummy" batteries (false battery attached to main DC power source) in their workdesk's, so they don't want N900 to put power back into main by any means

Everything above is correct only if (we assume that it will work at all, of course) there is no real serious hardware damage to charging chip. Which I think is most unlikely - keep in mind that joerg_rw seems to think otherwise, and he is MUCH (threat MUCH as multiplied by n times ) more experienced than me.

So only time will tell

Originally Posted by joerg_rw

BSI resistor in a normal BL-5J is 100k-Ohm, this is a relatively high resistance. So any "shorts" in battery and at battery connector in device caused by dust, humidity, whatnot else, may easily cause this to get out of range.
Again, my suggestion is to clean the contacts and isolating material around the contacts, and maybe even open up the device and clean the inside so there are no "short circuits" caused by dust or residue from getting wet, which will cause the 100k value to get "detuned".
jOERG

Originally Posted by joerg_rw

Another rather weird idea tha comes to mind is the modem and its firmware are interfering with the OMAP BSI AD-conversion, in a way that switched modem's BSI sensing pin to an output or to internal pullup/down-resistor and so creates additional load to the circuit