Battery discharging while phone is off (GSM part)

[fabchevalier@…]

My neo exhibits a very strange behaviour : after a full charge of the battery,
it takes only ~ 48hours for the battery to discharge completely to the point Neo
can't boot, while the Neo is *powered off*.

Looks like it is a well known problem :-) : see
​http://lists.openmoko.org/pipermail/device-owners/2007-August/000398.html

[fabchevalier@…]

One more detail : phone is a GTA01Bv4 phase 1 sold through web shop, so this
doesn't look like a duplicate of #482

[fabchevalier@…]

Quoting a recent mail from on device-owners ML:

"I hooked up a current meter between my battery and the phone, and noted that my
Neo draws around 41mA (meter not calibrated recently) after turning on then off.

The -P option with the shutdown command doesn't seem to have an effect on this.
As Fabien noted, if I physically disconnect the battery for a few moments after

shutting down, then reconnect it, the phone draws much less current,
approximately 70uA, which is why the battery does not drain overnight. Another
interesting thing I noted was that if I only disconnect the battery for a very
short time (maybe 1 second), the phone then draws 14mA instead of 41."

Any way we could have some tips from FIC ?
Does it look like a BUG or un unimplemented feature ? (Like making sure all bits
are powered off before to shut down the s3c241O)

Cheers,

Fabien

[laforge@…]

yes, this is sort-of a known issue. It seems not all peripherals are properly
turned off before shutting down the PMU. Especially the GSM part most
definitely is still on, unless it receives and AT@POFF on the UART prior to
shutdown.

the gsmd init script should take care of that, which it most likely doesn't.

In GTA02 we have addressed this by hardware, i.e. GSM will automatically be
switched off once the PMU shuts down.

Another potential issue is the audio amplifier (see #781).

So while this is known for a long time, our extremely small and overloaded team
just didn't have time to implement it yet.

[laforge@…]

changing this bug to cover the GSM side only. maybe somebody can verify that
AT@POFF indeed helps (i.e. manually issue it before power-down). Once we have a
tested patch for the gsmd init script, I'm more than sure alphaone would be
happy to apply it.

[fabchevalier@…]

Hi Harald,

Thanks for the tips, this is more than enough to get me started at fixing this
issue. :-)

I'm gonna try what you suggested over the week end, and hopefully come up with a
patch for it.

Cheers,

Fabien

[mickey@…]

Putting this into the init script seems to be like a layering violation -- after
all the gsmd is supposed to talk to the modem. Can't we put this into a
detaching method inside our machine plugin?

[fabchevalier@…]

Didn't make any progress, due to #788 insisting on crashing my phone.

My 0.02 cents about layering violation concerns:
It looks like the gsmd init scripts is responsible for power management, so we
have either to make the init script aware of AT commands or the gsmd aware of
power management: i don't know which is the worst ;-)

Cheers,

Fabien

[sean_chiang@…]

Harald!
For the GTA01BV4 green pcb, before phone is off, power off audio amplifier and
send AT@POFF to GSM modem, the current become 0mA finally. So, AT@POFF is
workable. BTW, when modem receive this command, you could not get any response
from modem.

[mickey@…]

AT@POFF works fine.