XO Troubleshooting Battery

  This page is monitored by the OLPC team.

This is the portion of the XO Troubleshooting Guide for diagnosing problems with the battery and power on an XO laptop.

The battery connector in the bottom part of the laptop

Start Here

What problem are you experiencing with your laptop ?

The laptop won't run using the battery

If the laptop functions fine using a known good test battery, the battery should be replaced.

If the laptop doesn't function from a known good test battery, see Diagnosing Battery Problems.

The battery light is flashing red

If the battery light is flashing red, this usually indicates an error with the battery. Try a full reset. If the problem persists, then the battery should be replaced.

If the replacement battery shows the same flashing red battery charge light, see common causes for lack of battery presence, below.

It is possible to obtain more information about the battery, and possibly repair it. See below.

The laptop can't charge the battery

If the laptop can charge a known good test battery, the battery should be replaced.

If the laptop can't charge the known good test battery, see Diagnosing Battery Problems.

The laptop won't run using the power adapter

If the laptop runs fine using a known good power adapter, the power adapter should be replaced.

If the laptop can't run from a known good power source:

• Does the battery charge LED still indicate the laptop thinks it has power ?
• Otherwise, the motherboard need repair:
  • Check the fuse (F1) and diode (D21) on the motherboard protecting the DC input
  • If the fuse was blown, check diode D123 and 38V zener diode D118 to see if they are OK.

The laptop emits a high pitched whine when using the power adapter

Working on this one

Diagnosing Battery Problems

Charging of the battery, and interpretation of the front panel buttons, is under the control of a separate microprocessor in the laptop, the Embedded Controller (EC). In order to ensure that battery communications are being properly handled, we must first establish that the EC is operating correctly:

Did the EC boot?

Follow the Full Reset procedure, and check to see if the battery LED flashes orange momentarily after reapplying power.

If it didn't flash at all, you probably have a broken motherboard. If it flashed another color (red or green), then you probably have a problem with the LED driver circuitry.

Does the EC recognize the battery?

When a battery is inserted into the laptop, the EC reads information about that battery from a integrated circuit inside the battery. If the EC does not receive valid information from this read, it will either assume that a battery does not exist, or report an error. The following tests tell if the EC is talking the battery correctly.

Does the battery light respond to changes in external power?

When you apply external power, the battery led should light up in one of four states:

• solid green - indicates a fully charged battery
• solid yellow - indicates a battery being charged
• solid red - indicates a battery in dire need of charging
• flashing red - indicates a battery error. See above and a detailed explanation below.

If the battery light does not indicate one of these states (e.g. nothing lights up) then the battery is not being recognized. If you get a solid battery light then the EC has successfully read the battery gauge. If the battery light stays unlit then either the battery is not recognized or the data read has confused the EC. Use one of the following methods to manually check for battery presence to determine the problem.

Checking for battery presence

The following methods may be used to manually check for battery presence.

Using Linux

Linux has an interface to the laptop's battery subsystem. Its available via sysfs at /sys/class/power_supply/olpc_battery/. The value of 'present' indicates if the EC thinks a battery exists. To check this value use the 'cat' command in the terminal app or at a vtty:

cat /sys/class/power_supply/olpc_battery/present

Using OpenFirmware

You will need a developer key for the laptop. Open Firmware has command that will talk to the EC and read the current battery info. This command is watch-battery. At the Open Firmware command prompt do:

ok watch-battery

If EC thinks a battery exists you should see a single line that gets updated with various pieces of battery information. If a battery does not exist then that will be indicated with a 'No battery' rather than battery status info.

Using OpenFirmware and batman.fth

You will need a developer key for the laptop. Batman.fth has comands that can interrogate the state machine of the EC's 1-wire interface. This allows you to see what's happening on the 1-wire bus. The command for this is see-bstate. If a battery is not detected the numbers printed will cycle between 0,1 and 2. Numbers other than that indicate the EC has detected a battery.

Common Causes for lack of battery presence

There are a number of possible causes for lack of battery presence. Here they are, in the order in which they should be checked.

Unplugged cable

The battery connector in the bottom part of the laptop

Check to see that connectors CN21 and CN22 on the motherboard are firmly plugged in. There is a second connector, hidden in the bottom part of the laptop.

Broken Wire

If no batteries are detected, a break or bad connection between CN22 on the motherboard and the data pin on the battery connector results in no 1-wire communication (seen as this problem). Check continuity of the cable with an ohm meter.

add pictures

Bad data in battery EEPROM

Normally if the data in the EEPROM has been corrupted a flashing red LED error will result. However, depending on the corruption it may be possible to confuse the EC. Use a known good battery to ensure that the problem is with the battery and not the laptop.

A battery in this condition can be detected by watching the output of see-bstate.

One-wire Communication Error

The sensor inside the battery could be malfunctioning or the output from the EC could be corrupted from a manufacturing defect. If the laptop cannot communicate with the known good battery, and you have already checked for an unplugged cable or broken wire, then the error is in the laptop motherboard and it will need replacement.

Battery LED is flashing red

Flashing red LED indicates that the battery subsystem has detected an error. Open Firmware has a command that will read the error code from the EC. The command for this is 'ec-abnormal@'. At the Open Firmware use the following to view the error code.

ok ec-abnormal@ .

Note the '.' at the end. This is required to print the error code.

The error conditions should be listed...

Battery fails to charge?

Checking the actual charge level

olpc-pwr_log is a Linux bash script that allows you to measure the amount of charge delivered to or extracted from the battery. It can be used to determine if the battery is performing at its rated capacity.

Laptop abruptly shuts off before battery is capacity reaches < 10%

See above

Experimental LiFePO4 Recovery Procedure

Problem Symptoms

A small percentage of LiFePO4 batteries are exhibiting a problem where they do not charge correctly. The parameters that the EC watches while charging change in such a way that the EC thinks the battery is full and marks it as full. On some batteries this seems to happen in the first few minutes and on others it happens much later on. The end result in all cases is an abrupt shutoff when the voltage on the battery drops below the critical level where it can sustain operation. This is currently believed to be caused by a cell imbalance but full analysis is still pending.

Verifying the problem

The first step in verify if this is the problem with your battery is to check what the current capacity is. The tool to do this is olpc-pwr_log. To use the script download it and copy it to your XO via a usb disk, SD card, or download it directly with wget.

wget http://dev.laptop.org/~rsmith/olpc-pwr_log

There have been a few reports of windows corrupting the file when it downloads it. If you download from a computer running a Windows OS then please get the .zip version instead and extract it to your storage media. olpc-pwr_log.zip is located in the same place as olpc-pwr_log.

Once its downloaded and on the XO then make sure its executable by typing

chmod +x olpc-pwr_log

Then you run the script with

./olpc-pwr_log

After a battery is detected A series of numbers will start listing on the screen. See XO_Power_Draw for the details.

The basic procedure:

1. plug up your XO to ext power and allow the battery to charge until the EC thinks it is full ie. green charge LED lit.
2. start olpc-pwr_log and let it report at least 1 line of data
3. unplug external power
4. let the XO run on battery until it dies
5. remove the battery
6. power the XO back up on ext power without the battery.
7. start olpc-pwr_log
8. insert the battery
9. allow the battery to charge until the charge LED is green again.
10. exit the script with 'ctrl-c'

Exceptions:

In many cases the battery despite being very low will have marked as fully charged by the EC. If this is the case then the EC will not attempt to enable the charging circuits. Yet if you unplug external power the XO shuts down immediately or within a few seconds and the battery is not marked as low. In this state its not possible to obtain any data with olpc-pwr_log. To fix this batman.fth allows you to reset the state of the battery and manually mark it low. This allows the EC to resync with the actual state of the battery and allow charging to be enabled. See tools for the details.

Reading the log file

The numbers we care about for for diagnosing this problem are SOC (column 2), Voltage in uV (column 3), Current in uA (column 4) and Net ACR in mAh (last column). In batteries that are suffering from the "won't charge" problem the CV point (7.4Volts) of the batter is reached much too soon. Then the voltage continues to rise and when it reaches above 7.5V the over voltage shutoff of the battery is activated. The EC sees senses that the current has dropped below the level that indicates the battery is full and marks it full even though very little charge was delivered to the battery. This pattern is fairy easy to recognize. Below is an example:

1214213331,72,6524560,1418229,3192,898,Charging,72,0

<time passes>

1214213649,76,7116870,1293098,3544,1185,Charging,76,119
1214213659,76,7171770,1280208,3560,1194,Charging,76,123
1214213670,76,7241920,1266536,3578,1203,Charging,76,127
1214213680,76,7511540,130,3589,1205,Not charging,76,127
1214213690,76,7507880,260,3576,1205,Not charging,76,127
1214213701,76,7511540,0,3567,1205,Not charging,76,127
1214213711,81,7506660,130,3551,1205,Not charging,81,127
1214213721,81,7512150,260,3539,1205,Not charging,81,127
1214213732,81,7510320,130,3521,1205,Not charging,81,127
1214213742,81,7510320,390,3508,1205,Not charging,81,127
1214213752,81,7506050,390,3493,1205,Not charging,81,127
1214213763,97,6745990,390,3477,1205,Full,97,127

In the above log the charging current is running along line normal at about 1.2 amps but at time 1214213680 the voltage suddenly jumps to 7.5V and the current falls to 130 uA which is down in the sensor noise. The EC first switches to CV mode (time 1214213711) and then when in CV mode and the charge current is < 200mA the EC marks the battery as full. This happens in the space of 114 seconds (1214213763-1214213649). This is much to quick. A normal charge would take a lot longer. The key measurement however is the net ACR which is the last column. It shows that across the entire time olpc-pwr_log was running the charging system only delivered 127 mAh. The LiFePO4 batteries are rated between 2800 and 3100 mAh so for a full continuous charge this number should be at least 2800 mAh. Anything less for a new battery means that your battery is not providing its rated capacity.

If you batteries are old then a slight decrease is normal. Each battery charge/discharge cycle decreases the capacity of a battery a tiny bit. The OLPC batteries are rated for at least 50% remaining capacity after 2000 cycles. This means if you discharge/charge your battery every day then you will lose about 9% per year.

If you have any questions about the data reported in the olpc-pwr_log then open a help ticket by sending e-mail to help at laptop dot org with your log file attached and someone will help answer your questions.

Recovery Procedure

By using a slow charge procedure it appears to be possible to recover the problem batteries. The long term results of this procedure are still unknown which is why its still considered experimental. The procedure itself is simple but since each case is unique it requires the user to watch for some conditions to be met and for other conditions which require a restart of the procedure recording the results of each stage. It also take a long time. Typically 30 - 40 hours worth of charge.

The procedure:

1. obtain a developer key and unlock the XO
2. discharge your battery by running the XO on battery until it shuts off.
3. remove the battery
4. power up the XO and go to the 'ok' prompt
5. fload batman.fth
6. insert the battery
7. run bat-recover
8. watch and wait

At this stage the screen should start streaming lines of data. This data is similar to the data reported by olpc-pwr_log but it being read directly from the the gas gauge rather than reported from the EC. The 'bat-recover' command plays with the charging system in a way that limits the amount of current used to charge the battery. The idea behind bat-recover is to slow charge the battery and keep the voltage from rising above the over voltage trip point. This allows the unbalanced cell to charge up while not damaging the cell that is fully charged. Until the battery voltage begins to approach 7.4V bat-recover seems to do a good job. However when the bat voltage nears 7.4V the over voltage circuit does periodically get tripped. When this happens the XO needs to be reset and the procedure needs to be re-started.

The data reported to the screen is:

Battery temp, Battery current, Battery voltage and Net ACR. Each value has the units after it.

Current, Voltage and Net ACR are the values that need to be monitored.

A perfect charge run would be a continuous run until the voltage rises to 7.4V and the current falls below 200mA. The net ACR delivered in this case should be about 3000 mAh or greater. The exact number depends on how low the battery was when the procedure was started.

A non-perfect run will trip the over voltage and require several stages. Since the charging current is limited to < 200mA for the entire procedure it can be difficult to tell the difference between a fully charged battery and one where the cells are still out of balance and causing over voltage to trip. To tell the difference the net ACR across each stage needs to be tracked. Every time a stage is restarted the net ACR is reset. Therefor while running the procedure the total ACR delivered should be monitored. The battery can be assumed to be fully charged when its reached 7.4 volts and you have delivered 3000 mAh or more worth of charge.

If the problem battery is continually tripping the over voltage without getting anywhere near 3000 mAh of charge then please e-mail OLPC (help at laptop dot org) with the summary of your results.

Software Tools

olpc-pwr_log

Currently this tool is located at http://dev.laptop.org/~rsmith/olpc-pwr_log

To use olpc-pwr_log follow the following procedure:

1. Copy (or download) olcp-pwr_log to the XO. It does not need any special priviledge
2. Start it

The script will wait until it detects a battery and then begin to log various parameters via the olpc-battery subsystem. If you battery is really low and the EC is using trickle charge rather than main charge then the script will appear to be still looking for a battery even though the yellow charge light is on. Once the EC finishes trickle charging it will report that a valid battery is present and the script will continue.

The output of the script is both to the screen and to a file. The file name is 'pwr-<date>-<gauge ID>.csv'. Gauge ID is a unique ID number that is contained in the gas gague of each battery.

More details can be found here olpc_pwr_log

batman.fth

Batman.fth is a forth script that is available from [1]. To use it you must load it at an Open Firmware (OFW) prompt. Getting to an OFW prompt requires a developer key. At the OFW prompt the script is loaded with the 'fload' command specifying the storage device where bathman.fth is located. Examples:

USB disk:

fload usb:\batman.fth

SD card:

fload sd:\batman.fth

Nand:

fload nand:\batman.fth

Once loaded you run the commands in the script just like any other OpenFirmware command.

Key tools in batman.fth

The following is a list of useful tools in batman.fth with a brief note how to use them. Some of these commands require that the EC be but in reset prior to running them so that the EC batter management system is disabled. The 1w-init command does this. After the 1w-init command is used all keyboard, touchpad and button activity is disabled. Including the power button. This means that any command requiring a 1w-init will require you to completely power off the XO by removing both external power and the battery.

• 1w-init

Put the EC in reset and prepare the system so that openfirmware can talk directly to the gas gauge chip in the battery. All keyboard, touchpad and button activity is disabled after this command. Required prior so some of the other commands.

• see-bstate

Continually prints the EC 1-wire communication state machine index. Useful for determining if the EC can talk to the battery gas gague.

Does not need 1w-init.

ok see-bstate

• bat-recover

Does PWM on the charge enable line resulting in a psuedo-current limited charge of the battery. Streams the current battery temperature, currrent, voltage and net ACR to the screen.

Automatically runs 1w-init

ok bat-recover

• bat-set-low

Zeros out various values in the battery's gas guage EEPROM forcing the EC to resync with the state of the battery. Useful if your battery is marked as full when it really is not.

Needs 1w-init

ok 1w-init bat-set-low

Linux battery subsystem

More information needed here