My Gta02s wont charge

[Joerg Reisenweber]

Am So  22. Juni 2008 schrieb Andy Green:
> Somebody in the thread at some point said:
> | Am So  22. Juni 2008 schrieb Werner Almesberger:
> |> Joerg Reisenweber wrote:
> |>> I think battery charging *never* may be turned off.
> |> That's my understanding so far as well. What bothers me is that I can't
> |> the device to show the symptoms I would expect in the various states,
> |> both good and bad symptoms.
> 
> | That's when I made a comment to the effect that we probably don't care
> about
> | our battery the way we should, some time ago.
> | Charging of battery has to be autonomous by PCF506xx, and all we need
> to care
> | about is to ENABLE it, and to *set the right currents and voltages*
> for PMU's
> | charger (and handle errors / monitor charging state). This has to be
> | done/redone (as often and) as early in boot as possible, to guarantee
> there
> | never will be set a too high max voltage (would kill battery) or charging
> | disabled (also by any error-condition [e.g. overvoltage] which has to be
> | handled and reset) which would lead to the deadlock Steve faces now.
> | 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!
Battery management is one of the main functions of PMU PCF506xx, and only of 
PMU. The CPU just has to set up the registers to meet the actual battery (and 
handle "emergency stops" asserted by PMU when things went wrong badly in a 
way that normally mustn't happen and thus is beyond PMU's scope). Nothing 
more, nothing less, nothing else. Period.
> What makes the trouble is the setting is sticky 
that's an *option*, no trouble!
> and  
> there is no always-on intelligence to reassess the situation when power
> does come 
Sure there is: inside PMU!
> (and according to what Werner just wrote, we can't make the 
> CPU do that job either).

> 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 
*allways* on. I agree there's quite some "maze" in setting up the PMU when we 
start up system (CPU core voltage etc), but REenabling battery charging 
surely isn't any part of this, in the first place. I repeat: Charging stops 
automatically (on Vmax). It resumes automatically (if Vbat<Vmax and 
external_power). No need to ever disable. Instead ENABLE whenever you "walk 
by" and rely on it's sticky. So Neo will charge even when not booting at all, 
even when battery is below Vmin - just plug in some USB.

> 
> On the charging settings for the battery, it seems to use a constant
> voltage mode for at least the latter part of the charging, because if
> you hook up an ammeter you will see the current decreases visibly second
> by second as the charger needs to push less and less current in to keep
> the charging voltage up.  So this is pretty adaptive. 
Exactly. We have to take care this constant voltage accommodates our battery, 
and this is the default state we are supposed to and actually should keep the 
PMU in, NOT disable charging all together.

> The temperature 
> of the cell never goes above 30 degrees here, you would expect to be
> toasting marshmallows on the thing if there was problem?

The only problem is: when we (that is PMU) don't care about max voltage *and* 
min voltage (=guarantee correct settings for these PMU-reg values, by setting 
them as frequently as appropriate), the battery's protection circuit will do. 
This should **NEVER** happen, cause it's one step from fireworks, and it 
introduces the problems Werner mentioned on another post in this thread 
recently.
 And to answer Werner's question: no, the battery internal protection circuit 
will reset from undervoltage ONLY when some *charging* happens, no way to 
reset itself by chemical recovery or sth. But in the first place, this 
internal prot NEVER should trigger, it's PMU's damn task to stop discharge 
*before* this happens. This is what I mentioned with "we don't treat right 
our battery".

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.

cheers
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/08a31bb3/attachment.pgp