How can I recover a bum battery?

[Richard A. Smith]

On 05/23/2010 02:37 PM, Mikus Grinbergs wrote:

> I booted the 1.5 on AC (without the battery).  Entered 'see-bstate' at
> the ok prompt - saw string of '0 3' repeating.  Inserted bum battery.
> The Battery_LED on the 1.5 soon changed to yellow.  Took the battery out
> of the 1.5 and put it into the "testing" XO-1.  Battery_LED still yellow
> when AC power plugged in.  Eventually, Battery_LED turned green.  I'm
> concluding this problem battery is now o.k., too.  Thanks.

Most of the reasons XO-1 firmware would silently ignore the battery were 
just silly.  In my large battery refactor (q3a36) many of those went away.

> that the Battery_LED was no longer dark, I did not repeat trying to
> capture those "first things 'see-bstate' did after battery insertion".

No worries.  It would only have been useful if it _didn't_ work.  I know 
what happens when works. :)

> My guess is that the better "support" in the XO-1.5, plus the procedure
> of inserting the battery *while* 'see-bstate' was running, was enough to
> "kick-start" the shadow ram in the battery (which had previously been
> "reset" by running 'bat-rewrite-life' on the XO-1).

see-bstate is merely an observer with no influence.  The 1.5 firmware 
simply does a better job at dealing with unexpected values.

> I've got q3a39b in my XO-1.5.  If I remember correctly, just putting the
> bum battery into the 1.5, then plugging in the AC, did not cause the
> Battery_LED to light up.

Interesting.  I've got your snapshots of what things looked like in the 
failed case.  I'll program a battery with those values and see what it does.

> Yes, the 1.5 OFW does have 'bat-debug-log'.  Does that command take the
> name of its output file as a parameter?  I did not get around to running
> that command.

As James says it creates its own log file on whatever media you have as 
"disk" which is USB or SD depending on whats discovered.

> Thanks for helping me recover my bum batteries.  I did not know that
> 'bat-rewrite-life' (and 'bat-debug-log') existed.

Rewriting the values is a sledgehammer fix so I don't recommend it 
without looking at the values first to see whats up.  Prior to the ESD 
discovery it was a mystery where the corruption was coming from and it 
happens so infrequently that I wanted to see as many cases of it as 
possible.

  How to use them (and
> other useful commands) is the kind of information that would be helpful
> to distribute to places where XOs get repaired.

Indeed.  Perhaps you would like to summarize the email exchange and add 
it to the troubleshooting guide?  It could use some updating.

Now that the cause of the corruption is known its less of an issue to 
just rewrite the values.  And with LiFe there is little harm.  95% of 
the values in that eeprom are for the NiMH chemistry and its complex 
algorithm.  The values are updated real time.  So overwriting destroys 
the current state of the battery.

In contrast the LiFe algorithm is trival, only a few locations are used 
and destroying them doesn't really hurt except that your SOC will be out 
of whack for a while.

-- 
Richard A. Smith  <richard at laptop.org>
One Laptop per Child