Charging seems completely broken

[mickey@…]

Both Sean and mine GTABv03 exhibit the same behaviour.
Once the battery is below a certain level, it can't be charged anymore.
Neither with a wall-plug nor via USB. The device keeps sitting there dead.
We even tried to leave it for 12h with the wall-plug charger (should make 100mA,
right?), but it remained dead. It instantaneously worked again when we got lend
a (interestingly 100% compatible) Nokia BL5C.

[laforge@…]

This is really intersting. I have tested this with my GTA01Bv3, and could not
observe the same problem.

I will try this again with different units and different batteries.

[cworth@…]

I've replicated the problem with my GTA01B_V3. Wehn I received it the battery
was charged and the device booted to Linux fine.

Then I let the battery run down. And since then, if I plug it in, (to either the
wall charger or to my laptop via USB), it goes into a 7 second loop, (giving the
vibrator a quick buzz, and momentarily flashing the openmoko flash image, then
off agin). I left it on the charger overnight and the behavior didn't change.

I'm still trying to find a local shope to purchase a replacement battery, (or
better, an external charger), so I can get started hacking on this little
gadget. :-|

-Carl

[laforge@…]

This is really strange. I have not been able to reproduce this ever with any my
devices and/or batteries. So it might be some bug that only shows up in
particular phones.

Carl [or anyone else who has that problem]: When you insert a charged (original
or replacement) battery into the device, please immediately access the u-boot
prompt and send me [attach to this bug] the output of

1) neo1973 charger state
2) imd 0x08 0x00 0x30

This will enable os to look at the charger registers.

thanks!

[cworth@…]

Oh, looks like I didn't get emailed on this bug, (I suppose I need to explicitly
add my address to the CC).

I went out and bought a BL-5C so I could boot, and then started poking around to
learn how to play with this device. Only then did I find out I should be holding
down the aux button to get to the u-boot prompt.

So, that made me think to go try the old dead battery while holding down the aux
button. I did that and the u-boot menu came up fine. Then I power cycled and the
machine is booting just fine with the original battery.

So, I seem to have pushed past the bug somehow, (though I don't know if it was
due to booting with a fresh battery or due to interrupting the boot with the aux
button).

I'll certainly let you know if I run into the problem again.

And I can still report some of the register settings, (though I don't know if
they will be indicative of the buggy state anymore).

-Carl

[cworth@…]

Like I said, I don't know if this is useful anymore since my device no longer
seems to be exhibiting the buggy behavior. But here it is for what it's worth:

GTA01Bv3 # neo1973 charger status
pre
GTA01Bv3 # imd 0x08 0x00 0x30
0000: 4d fb 00 00 00 40 00 08 70 05 33 30 19 00 01 01 M....@..p.30....
0010: 00 7f 7f 3f 07 3f 1f ff 00 00 ff 18 00 00 30 e8 ...?.?........0.
0020: 00 e4 30 f8 16 10 00 f8 00 05 00 1a 55 13 00 00 ..0.........U...

-Carl

[alphaone@…]

This is the output from my Neo with a half empty battery. I also encountered the
7 second loop last night. I'll let the battery run low again today to see if the
problem persists.

GTA01Bv3 # neo1973 charger state
pre
GTA01Bv3 # imd 0x08 0x00 0x30
eo 4d 7b 00 05 40 40 00 08 70 05 03 23 01 05 09 02 M{..@@..p..#....
0010: 07 7f 7f 3f 07 3f 1f ff 00 00 ff 18 00 00 30 e8 ...?.?........0.
0020: 00 e4 30 f8 16 10 00 f8 00 05 00 1a 55 13 00 00 ..0.........U...
GTA01Bv3 #

[cworth@…]

This is the output from my Neo with a half empty battery. I also encountered the
7 second loop last night. I'll let the battery run low again today to see if the
problem persists.

Daniel, I'm curious: What did you do to get your neo out of that state?

-Carl

[alphaone@…]

Carl: I adapted http://people.openezx.org/alphaone/pics/charger.jpg for the Neo
battery :-)

One thing I just observed:
root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/battemp
50

So maybe the overtemp protetction prevents the battery from being charged properly.

[cworth@…]

After having my neo booted and plugged in (to my laptop) for about a day, I
observed the same behavior again, (which suggests that there's at least an
additional problem besides the device not charging with a completely dead battery).

So I tried holding down the AUX button while the device was in its 7-second loop
again. I didn't manage to get that to do anything except for interrupting the
looping.

Then, after leaving the device unplugged for a short time, (just a few minutes
really), I plugged it in and noticed a change: When I get the looping behavior
it starts with the vibrate-and-splash-screen as soon as I plug it in. But this
time, I plugged it in and it did nothing at all. So I waited another few minutes
before pressing the power button, and then it booted successfully.

I know that's a description of only rather gross behavior, but perhaps there's
something in there that might trigger an idea as to what could be causing the bug.

-Carl

[oe@…]

( FWIW I've updated u-boot to u-boot-gta01bv3-r2_0_1287.bin yesterday.)

I left the phone connected to a powered USB hub (which itself is connected to a
running notebook) over night. However, the next morning I tried to turn it on
and was greeted by the above bug :\

Here is the work-around that worked for me:

• When the phone is on a reboot frenzy, push the PWR button exactly _once_ This stopped the rebooting for me.
• Let the phone charge for a few minutes
• Launch into the boot-menu and access the u-boot prompt.
• Run the command "neo charge fast"
• Let the phone charge for a while

[laforge@…]

I think what might happen here is that we get into some loop where

1) the PMU decides that the battery voltage is high enough to boot
2) it switches on the CPU, which in turn switches on various peripherals, most
notably high-power peripherals such as backlight
3) due to the high current draw, the battery voltage decreases below the
threshold of the PMU
4) the PMU powers the device off
5) due to no more current draw [or 100mA charger], the battery voltage increases
again to a level above the threshold
6) GOTO 1

So the big question is how to prevent this from happening.

a) we could set a higher Vlowbat (minimum battery voltage) threshold. This
sucks because we would shut down the phone even before the battery is empty.

b) we could put some heuristics into u-boot to find out if many reboots are
happening in too short a timeframe. If we can detect this, we still need a way
to prevent it happening again and again. We need to find out for what reason
the PMU decides to power up in the first place.

In order to debug this, I would recommend (Werner?) a patch to u-boot which
dumps the 'power up reason' and interrupt as well as battery voltage monitor
registers to the serial port. This means once we get into the loop, we should
get those registers on the serial console and can deduct what's happening

[cworth@…]

Harald wrote:

1) the PMU decides that the battery voltage is high enough to boot
2) it switches on the CPU, which in turn switches on various peripherals, most
notably high-power peripherals such as backlight
3) due to the high current draw, the battery voltage decreases below the
threshold of the PMU

...

a) we could set a higher Vlowbat (minimum battery voltage) threshold. This
sucks because we would shut down the phone even before the battery is empty.

So is this just a case of missing hysteresis? That is, is there a single
threshold value that is being examined in steps 1 and 3 above? If so, could the
answer be as simple as using separate values and raising the value for step 1
while leaving the value for step 3 where it is?

-Carl

[werner@…]

Here's how one can reproduce at least some of the symptoms on my bv2.
Be sure you know what you're doing. If you reverse the polarity,
all you're likely to get is a heap of smoking misery. All readings
are from the lab supply. I didn't measure what's going on on USB.

- remove the battery
- set the voltage of your lab power supply to 3.0V
- hook up your lab supply instead the the battery (careful !)
- set the current limit high (above 300 mA)
- connect USB
- your voltage readout on the lab supply should jump to about 4.1V
- turn your Neo on. You should now get, on the lab supply, up to

250 mA and 3.0V

- while the system is running, limit the current to about 220 mA
- the system should reset, make it to the splash screen, reset

again, etc.

- briefly press the power button to end this
- power on repeats the cycle
- you can reduce the time the splash screen is shown by limiting the

current further. The minimum is about 150 mA.

- you'll notice that each cycle lasts about 1.25 seconds
- limit the current to about 90 mA
- all of a sudden, the cycles get quicker, about 0.6 seconds
- pressing the power button no longer has any effect now
- if I disconnect and reconnect USB, the machine happily enters the

same cycle again

- further lowering the current accelerates the cycle to about 120 ms
- this goes on until I limit the current to nominally zero
- even at "zero", the cycle is restarted as soon as both USB and

battery power are present (no matter in which order)

Note that my bv2 is "naked". In particular, it doesn't have a vibrator,
which may change some of the results.

- Werner

[laforge@…]

Carl: The hysteresis is determined by hardware (on-die of our PMU, datasheet is
linked from the wiki), so there's nothing we could configure.

[mail@…]

Had the same issue, confirm that Carl's Aux-button method helps get past the loop.

However, I note that charging seems incrediby slow. Even after many hours, I am
now only at 40% charge (attached to the supplied charger). Seems to be
trickle-charging instead of quick charging, because the battery isn't even warm.
Would this play a role?

BTW - the charger is only a USB 1.1 charger? I noticed that to refused to charge
my Palm devices via USB.

[mail@…]

Spoke too soon. Managed to get to the desktop, was able to play around a but.
Fired up battery applet, which reported that the battery was 40% charged.
Suddenly phone rebooted, and is now back in the loop. I cant break out of it.

[mail@…]

Yanked wife's Nokia phone battery and plugged it into my OM (needed some padding
to hold it in place). Booted perfectly fine. Battery level shows as 70%. Plugged
OM battery into wife's Nokia (doesn't fit, so have to hold it in place), phone
boots, and shows about 40% charge (inaccurate, going by number of bars on
battery meter). Put OM battery back into OM, goes into boot loop.

Now using wife's phone battery to work on the OM (situation works for me, but
not for the wife :). Trying to figure out how to charge the OM battery externally.

Question - why is the OM unable to work with its own battery at 40% charge? Does
it have to be at least 50%? Is this a calibration issue? Or a battery issue?

Will wait and see what happens when Nokia battery drops to 40% or less.

[mail@…]

More info to possible solution here:

http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=255

[werner@…]

I think (based on what I saw in my measurements) the threshold is about 2.7V.
If your battery is below that, or drops to that level under load, you're in
the loop. Also, if you have an interruptible loop and let it continue, it
will deteriorate into the non-interruptible loop.

I can offer one work-around: connect the debug board and hold the device in
reset. (E.g., by putting something non-metallic and heavy on the reset
button.) This should allow the battery to recharge peacefully.

If you don't have a debug board, you could trigger a reset also by pulling
H-TP1508 to GND. (Beware, I didn't try this.)

[mail@…]

I do have the debug board, but I found an easier way to get around it: I have a
Nokia N70 with a similar battery (BL-5C) that I "liberated" from the office lab.
Pretty painful phone (which is why no one was using it), but since the battery
works in the OM, the phone can be used as a battery charger.

Just for the record - the N70 will NOT charge the OM battery.

[werner@…]

I've made a partial fix:
trunk/src/target/u-boot/patches/early-powerdown.patch
Since this is experimental, it's not in
trunk/src/target/u-boot/patches/series. It should be placed between
uboot-20061030-neo1973.patch and uboot-s3c2410-misccr-definitions.patch

What it does: at the earliest opportunity, it checks if the phone was
woken up by the power button of an RTC event. If not, it powers down
immediately. This can be skipped by pressing the AUX button (e.g., if
you want to do just a software or hardware reset).

This gets the board out of the 1.2 and 0.6 second cycles. It doesn't
help against the 120 ms cycle, but that one may actually be just an
artefact of my test setup.

Unfortunately, this hack conflicts with the idea of powering up the
phone when a charger/PC is connected, so that the phone can request
500 mA from the USB host, instead of the meager 100 mA it gets by
default.

[alphaone@…]

Once Bug 255 is fixed you could check the voltage/capacity at boot and only
enter slow charging mode if it is below a given threshhold. Then the Neo could
check periodically (via RTC wakeup?) and boot into fast charging mode once the
battery is charged partially.

[werner@…]

The PMU takes care of properly feeding the battery. All we need to do is tell
it how much current it can draw from the charger. But the problem isn't
deciding how to charge the battery, but to avoid trying to bring up the
system when the battery is too weak.

If we have enough juice to last a whole 7 seconds, we could indeed do the
full USB protocol exchange with the host to get permission to use 500 mA
and/or detect the charger, which also lets us use maximum power.

However, I'm afraid that a battery that's even in worse shape may not give
us enough time to get that far. With the backlight turned off (but the LCM
receiving power), my bv2 still wants 160 mA from the battery while idling
in u-boot.

A possible solution may be to do the USB protocol exchange in u-boot before
anything else if the PMU indicates a charger connect (which can be
misleading). We should be able to do this while staying within the 100 mA
envelope. Once this is done, u-boot can return to standby mode and charge
at full speed.

If the PMU doesn't indicate a charger connect, the normal startup process
would happen. I.e., the user wouldn't have to wait for USB.

But I think we still need a mechanism to catch the phone if it enters that
vicious circle. Something slightly more sophisticated than my current hack,
but not too complex either.

[laforge@…]

Werner: Why does it still enter that loop? I thought by disabling EXTON and
just using CHGINS we can prevent the loop?

[werner@…]

CHGINS is also set. Disabling only EXTON is therefore of no use.

[mickey@…]

Quoting Nils Färber from the mailing list today:

=====
Hi!
I just recognised a little issue with battery charging...

Yesterday I put the NEO on the charger and let it boot. It booted up
fine and started charging the battery.

Today when I returned to my desk the NEO was constantly rebooting, i.e.
the splash showed up for a second, then went dark again, stayed dark for
about three to four seconds and started over again.

One possible way to explain this could be that after charging was
finished last night the charger was switched off and the device put back
into battery mode not using the AC adapter at all anymore. Subsequently
the battery drained completely until this morning which causes the
(know) reboot cycle.
=====

[laforge@…]

u-boot using svn rev. 1511 or later of our quilt patchset now have a
minimum power-on voltage of 3.3 (instead of 2.8V before). Let's hope
this finally solves #212.

Images can be found at
http://buildhost.openmoko.org/tmp/deploy/images/?C=M;O=D

Test reports are welcome :)

[alphaone@…]

I can confirm that the latest version of u-boot resolves this issue.

When charging a completely drained battery you have to be patient, though. It
took me more than 3 hours to charge the phone far enough that u-boot would allow
it to turn on again (You will have to press the power button). But then all was
fine.

[alphaone@…]

*** Bug 406 has been marked as a duplicate of this bug. ***