No battery Vsys issue is USB overcurrent?

Andy Green andy at openmoko.com
Mon Jun 30 16:02:05 CEST 2008


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

Somebody in the thread at some point said:
| Andy Green wrote:
|> I was up until 2am looking at the "charging problem"...
|
| It's a tricky beast, isn't it ? ;-)

It's just the usual: we didn't understand it yet.  But yes it is
complicated.

Did that mail you replied to go out on the list or what?  I didn't
receive a copy of it yet.

|> 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).
...
| So I think solving the "can't boot without battery" problem will also
| solve the charging issue.

Right.

| By the way, since you're seeing the same VB_SYS breakdown now, does
| this mean that your GTA02 now also refuses to do anything if there's
| no battery ?

Yeah the days when I had a GTA02 that came up with no battery were many
months ago.  Nowadays the ones I have "motorboat", that is, cycle the
power at 10Hz or so, and interestingly make a small "click" in the
microphone when that happens.

|> 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.
|
| That sounds plausible, yes. I estimated that the systems draws about
| 3W from the capacitor bypassing VB_SYS.

Wah for how long though?

|> 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",
|
| Ah, that's an interesting theory. The PMU's GPIOs are stable in
| Standby, so you could control the GSM power switch. However, our
| default should already do this right.
|
| There's something we don't control with this switch, and that's the
| RF amplifier. A radical way to test whether GSM is to blame would be
| to remove B1701 and see what happens.

I checked the enable for it last night, nothing.  There's another great
story for all this that didn't pan out, EN_USBHOST spike: the host side
power generation enabled defeats the path of USB power through to the
pcf50633.  That would have been a nice story but nope.

| When I added an external 47uF bypass to VB_SYS, I sometimes got the
| system to start, sometimes not. Adding 4.7uF made it almost always
| work. 47uF+4.7uF =~ 52uF. Could this be conincidence ?

I didn't see why it shouldn't be coincidence.  The fact is we get a 30us
dropout on Vsys, keep adding caps you can stop it dipping below a
critical level in the 30us.  If you want to talk coincidence ;-) there
is a third great story to explain it that didn't pan out: 30us is a
commonly used filter period in pcf50633 and is also the duration of the
ADC action.  One way to get the pcf50633 to power stuff down is if it
thinks there is overtemperature in battery, which it checks by running
ADC to measure it (ours isn't really connected to anything).  But I
checked the bias for the NTC and it does not get asserted during the
crisis, so it isn't that either.

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

iEYEARECAAYFAkho51cACgkQOjLpvpq7dMpZewCcDsuEu48ryAIbkMjHo2/zbThY
7fUAn2tNVIuELmtm0m5Rmd12PJ3asn4S
=aaI9
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list