My Gta02s wont charge / chgena = 0 by default

Joerg Reisenweber joerg at openmoko.org
Mon Jun 23 10:23:35 CEST 2008


Am Mo  23. Juni 2008 schrieb Andy Green:
> Somebody in the thread at some point said:
> 
> |> | It is utterly nonsense to intentionally disable battery charging in
> |> any time
> |> | whatsoever.
> |>
> |> In itself it's perfectly sane to tell the charger to standby if there is
> |> no power coming in.
> | No it isn't at all (if switching off PMU-charge-battery path is what
> you're
> | talking about). This function HAS TO BE ENABLED all the time (see your
> next
> | statement below). In the end what's the use of disabling charging when we
> | have no power to do charging anyway - it will be implicitly disabled and
> | comes back as soon as there is any power left over (besides powering the
> | system) to do so. See PCF50633-manual!
> 
> "In itself" means local to what I wrote... a generic charger with no
> power coming in can be put to standby because what else will it do with
> no power?  So that is generically a sane proposition.  I wrote that
> because you said: ''It is utterly nonsense to intentionally disable
> battery charging in any time whatsoever.''  For the pcf50633 case, I
> don't think you are ready to be so certain either, because when I look
> at MBCC1 reset state for our variant, I see it wakes up with chgena = 0,
> so the manufacturer disagrees with you.

No, don't think so. It's the manufacturer's way to say "set max voltage and 
max current etc, before you even think about enabling charging).
When we've done this, manufacturer does us the favor to make this 
state "sticky" so PMU will awake from backup-battery with whatever we decided 
it should. And it should awake with charging nicely configured and enabled.


> 
> |> What makes the trouble is the setting is sticky
> | that's an *option*, no trouble!
> 
> Werner seems to blame chgena being sticky in suspend for the failure to
> charge issue if I read him right (and it sounds right).
> 
> As for "option" you have to take care.  There are many registers which
> have a notation "this register is reset in NoPower state".  Because of
> the privileged position of pcf50633 in the power handling, there is a
> possible deadlock here where the default state of pcf50633 registers
> after NoPower does not suit us.  And the CPU being down then, with no
> other intelligence up, we have no control over that to modify it.
> NoPower comes when we not only have no power externally or in main
> battery but the backup battery is down too.  Other registers reset in
> standby.  It's a maze.
Yeah, but doesn't apply to our discussion here. We're talking about return 
from low-bat / suspend, not initial wakeup from a drained backup-bat.

> 
> If you look at MBCC7 in the datasheet and our variant data, there is no
> option here.  In suspend mode usbdevstat gets forced to 01 == 500mA.
> chgena is sticky in suspend and set = 0 in NoPower.  No option.
See above.

> 
> |> there is no always-on intelligence to reassess the situation when power
> |> does come
> | Sure there is: inside PMU!
> 
> ...
> 
> |> Instead what we're left with is trying to find
> |> a way through the maze of default fixed behaviours of the PMU and trying
> |> to match them with what we need.
> | No, we are actually building our own mace by disabling PMU-bat-charger,
> | instead of simplifying things by just make (as) sure (as possible) it's
> 
> I hope the other notes in this email make it clear we have little or no
> control over those actions, the variant decides it for us.
Nope, the variant decides about those registers that are reset on suspend, and 
it decides on the way the whole PMU comes up from NoPower. We are free to set 
the "sticky" registers to whatever we think is best for us.

> 
> | I'll have a closer look in this tomorrow, to name the correct
> PMU-registers
> | and values we need for them with our actual GTA02-battery.
> 
> We should be cautious about asserting mastery of the pcf50633: let's
> qualify our understandings until we proved it (and proved that we proved
> what we think we proved, since there are many settings floating about).
> ~ It's stung me a few times with letting myself think I understood the
> whole shebang only to realize I missed out on a whole layer of stuff
> going on quietly in there.  One thing is for sure we are at its mercy
> when no intelligence is up to control it, the pcf50633's default
> settings are master of our device.

We have proven we are able to come up from defaults - that's what every device 
is doing fist time it's powered up.
We may easily reset to defaults by draining backup-bat.
So where is the big caveat to meddle around with the sticky settings of 
charger?
But a agree with you we urgently need to qualify our understandings and check 
and recheck what we should set this stuff to. We could end up in a situation 
otherwise, where we erecommend to user: "wait a year or two until backup is 
drained, then buy a new main battery, boot and reflash" ;-)

/jOERG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080623/cede0af4/attachment.pgp 


More information about the openmoko-kernel mailing list