[SHR-Unstable] Forcing fast-charge
joerg at openmoko.org
Sat Apr 25 14:16:17 CEST 2009
Am Di 21. April 2009 schrieb Paul Fertser:
> Joerg Reisenweber <joerg at openmoko.org> writes:
> > Am So 19. April 2009 schrieb Rask Ingemann Lambertsen:
> >> On Sat, Apr 18, 2009 at 05:11:36PM -0700, Mike Montour wrote:
> >> > chg_curlim controls the battery charger, while usb_curlim controls the
> >> > total current that can be drawn from the USB port (charging + the
> >> > current used by the Freerunner).
> >> Note that whenever you set usb_curlim (directly or indirectly by
> >> plugging in power), chg_curlim is set to the new value of usb_curlim.
> > where do you find this info? I've checked shortly and e.g. 126.96.36.199
> > mention this relation. Maybe I didn't realize the important part?
> * We limit the charging current to be the USB current limit.
> * The reason is that on pcf50633, when it enters PMU Standby mode,
> * which it does when the device goes "off", the USB current limit
> * reverts to the variant default. In at least one common case, that
> * default is 500mA. By setting the charging current to be the same
> * as the USB limit we set here before PMU standby, we enforce it only
> * using the correct amount of current even when the USB current limit
> * gets reset to the wrong thing
Whoever wrote this amazingly puzzling comment, I think he got something
severely wrong with operating principles of PMU PCF50633.
Datasheet of PMU clearly states there's no situation whatever that could
result in batcharge current overloading the USB_CURLIM, as *allways* there
will be priority on serving system by providing up to 100% of usb current to
power it. Bat charge will get whatever might remain after that, *up_to* the
charging limit programmed into PMU.
As we may charge our battery with 1C (=1200mA) it's perfectly safe to set bat
chg curlim to that value, and rely on PMU managing distribution of actual USB
supply current to system and charging according to the momentary needs.
There have been issues regarding some glitch resulting in a very short
brownout on Vsys when *enabling* batcharge, but I don't think it's covered by
the explanation above, and anyway afaik this has been fixed with various
uBoot-patches and modifying the Vsys-buffering C (no boot on flat bat issue)
See my previous shorter post in this thread
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/community/attachments/20090425/be299a0b/attachment.pgp
More information about the community