From: Mike Holden <mike_at_mikeholden.uklinux.net>
Date: Thu, 6 Feb 2003 20:53:20 -0000 (GMT)

> Justin Heiner wrote:
>> Then why is it that when power management is totally disabled in the
>> FM recorder, it will boot? :-)
>
> It won't. Many FM owners report it still powers off without the charger
> cable.
>
>> Seems like rockbox is doing SOMETHING that is making it shut off
>
> I'd guess it's rather something Rockbox *isn't* doing that makes it shut
> off.

Ok, here's where I'm up to with debugging this, and I have _MOST_ of the
answer!!

The problem lies when the battery voltage is less than
BATTERY_LEVEL_DANGEROUS. This can be either because the voltage really is
less than that value, or if it _APPEARS_ to be because we often read power
values at or close to zero. This is why my recent patches sort it for most
cases, but maybe when Justin tested my first patch he was on low power
anyway.

To reproduce the problem, I artificially changed the value of
BATTERY_LEVEL_DANGEROUS (BLD from now on) to a high value and then to a
low value. My power was at 3.31, and I used values of 300 and 350 to
reproduce this, though any values should work.

The steps are as follows:
1. Plug in both power and usb, and update firmware.
2. Unplug usb (after unmounting/safely removing device in O/S!), but leave
power in.
3. Stop and start archos a couple of times to ensure new firmware is in use.
4. Pull the power plug.
If the value of BLD is higher than the current voltage, then Archos
immediately shuts down. If BLD is lower than current power, archos stays
on and functions normally.

This test scenario was 100% reproducible in both power settings for BLD.

After examining the code, I traced the problem to power_init() in
powermgmt.c, in the call to charger_enable(true), which is called in the
last but one section, just before calling create_thread(). If I comment
out the if() and subsequent call to charger_enable(true), then archos
boots fine and functions correctly, no matter what the setting of BLD.

The charger does not kick in immediately in this case, but it does start
from the normal runtime checking within a minute or so.

I don't understand what is happening at a low level in charger_enable, as
it is bitmasking binary values into the hardware, so I will leave the
final diagnosis down to someone who maybe understands it a bit better at
the hardware level!

Short-term fix is to disable the call to charger_enable(true) in
power_init(). The adc.c patch I submitted earlier today will smooth out
the power reporting in all screens, but will not be necessary to stop the
poweroffs if this other fix is done. Even with initial charging disabled
in this way, charging still commences very soon after bootup, so I don't
see this as a major problem, but of course a proper solution would be
nice!

Regards
Mike Holden
Received on 2003-02-06