No battery Vsys issue is USB overcurrent?

Andy Green andy at openmoko.com
Mon Jun 30 12:57:58 CEST 2008


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

Hi -

I was up until 2am looking at the "charging problem"... I believe this
is not a charging problem at all but precisely the old "I can't come up
without a battery" problem and nothing more (or, unfortunately, less).

Currently the hypothesis I am trying to work with is that we pull way
too much current at power up, and the loss of Vsys is a reasonable
response from the pcf50633.

This reaction is mentioned in p82 of the pcf datasheet:

''[3] CLIM indicates current limiting mode, resulting in a drop in VSYS
when in ISYS > ILIM(USB) (as set via usbdevstat; see Table 98).''

We know that usbdevstat is forced to 500mA by variant init in standby.
So for this explanation, we say

~ - we pull > 500mA from USB for some (short) period when the power rails
come up

~ - pcf50633 reacts by the documented current limit action on USB which
"result[s] in a drop in VSYS"

~ - if we have a good battery in then the normal power arrangements of
pcf50633 use the battery power to fill in the "drop in VSYS"

So where does all the power go?  I didn't find out yet (or indeed prove
it is true).

I sniffed around the GSM stuff for a while, because the charger action
can basically power it all since it is directly powered from "battery",
but it didn't seem to get its power enabled by the GSM power switch
despite having a couple of volts floating around in there.  There's a
separate current limit for charge, but maybe it can be set wrong and we
drive the GSM power amp or something.  But there was no real sign.

Then I noticed that although CORE_1V3 starts to come up (see
f0002tek.jpg pic), STBY_1V2 remains at 0V.  This is because it's an LDO
fed by IO_1V8; it isn't enabled until IO_1V8 reaches 1.6V and nothing
gets above 1.1V before the crisis on Vsys.  So there is a period before
the crisis where we have no CPU VDDALIVE but we have ~1V on the Arm Core
Vdd and IO Vdd on CPU.

p572 of the sc32442 datasheet says:

''(1) Because there is no level shifter between internal & alive block,
Alive current is increased when alive voltage is greater than internal
voltage by 0.3V. When using DVS in stop mode, assume the VDDi=1.0V, due
to the voltage gap between VDDi and VDDalive must not be over 0.3V,
recommend VDDalive is 1.2V.''

Maybe that can be it, but VDDalive remains at 0V not showing signs of
power leaking from another domain.

Another clue is that the rails that do come up all slope up at the same
time and reach around 1.1V at the time of the crisis, except the 1.8V
rail which is significantly down from that at about 0.6V (see f0006tek.jpg).

Or, it could be the wrong idea altogether, but USB overcurrent is at
least a coherent documented reason why we might see dips on Vsys.

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

iEYEARECAAYFAkhovC4ACgkQOjLpvpq7dMqBWACfYoTxHsQ2pzPgwTPYRK7ubWZt
SGsAniONTj2SV2/tNxpmrszwgyFX7RZf
=+NZT
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f0002tek.jpg
Type: image/jpeg
Size: 99374 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080630/53013577/attachment.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f0006tek.jpg
Type: image/jpeg
Size: 101886 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080630/53013577/attachment-0001.jpg 


More information about the openmoko-kernel mailing list