A5 Power routing "minor issues" for some modules

Andy Green andy at openmoko.com
Tue Feb 26 13:31:37 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi folks -

Thisafternoon I noticed that

 - vibrator

 - USB Host function (plug USB device into gta02)

 - whole GSM subsystem

are all powered specifically from Vb, which can be absent or unusably
reduced during operation without a battery due to charger state machine
actions.  Every now and again the charger wants to stop charging and
make a measurement of the battery's own voltage.... no battery in there
means no usable Vb then.  If we don't run the charger, there won't be
anything put on Vb at all in the USB-no-battery case.

It's not a huge deal though because you can run from USB with a battery
in there okay, and it will be powered from the USB 99% of the time,
including charging the battery.


A solution can be to move these guys to take power from the VB_SYS rail
which is the output of the power source summing stuff.  The chip has a
2.2A limit here on the chip from the battery to VB_SYS.

However I talked it over with Tony and he remembers bad things happening
with a similar idea for a switched GSM power rail on GTA02 A2, we dug
one out and it used a TPS2023...

http://focus.ti.com/docs/prod/folders/print/tps2023.html

It is rated quite similar to the Vb <-> VB_SYS switch in the pcf50633
(also specified for 2.2A max) and likely has a similar Rdson for the
switches (33mR for the TPS2023).  It's really not clear why that
solution made trouble, the standard reasons would be insufficient caps
and maybe too long a loop for the power, but eyeballing the board it's
not too far away from the GSM stuff (nor is the pcf50633 in the GTA02-A5
case), but that doesn't say anything about the routing.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHxAapOjLpvpq7dMoRAiMgAJ9UYN2NbyCVvDpwDuD4VobiTl5J6QCcCSnu
sWAv1bKuKcswb0WC2L5pQsk=
=X6xM
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list