Providing high current on battery pin from USB gets it booting

Andy Green andy at openmoko.com
Tue Jul 1 09:56:02 CEST 2008


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

Somebody in the thread at some point said:

|> | To test it might be a simple setup to feed some 3V to IO_3V3 from
|> external

|> Gah I read this as I just finished doing that test on STBY_1V2, 1V8 and
|> IO_3V3 rails from a second A5 that was powered first -- the first two
|> make no difference, but we get a good start on the unit under test if I
|> gave it "3V3 transfusion" from the other A5.  So good idea!
|>
|> This is clearly a big clue, but our PMU variant says that it current
|> limits the Auto regulator to 400mA during its startup.
|
| had no look at the particular power-up sequence. So just an idea:
precharge
| via a diode from some low-power lower-voltage more-early-in-sequence
| regulator?

There is no sequence on our PMU variant, it all comes up on "activation
phase 3" in a big lump, which doesn't help anything.  Except STBY_1V2
which is on an LDO off 1V8 and doesn't come up until 1V8 is 1V6 and
more.  But the transfusion test on that seems to show it isn't relevant.

I didn't understand why we appear to have large alleged-inrush current
at startup particularly on 3V3 rail.  I tried to remove the 47u last
night to see about the cap charging idea and managed to trash some
components around it :-( so I can't test this idea that the inrush is
coming from ~60u or whatever on 3.3V.  But at the time of the problem
the voltages are ramping slowly and do look constant-current (the ramp
into C is linear).  The voltages are at around 1V but we pull estimated
~10W on the regulator input side, it suggests instantaneous inrush
current up at ~10A since we are only at 1V :-/  But the current limit on
the 3.3V rail set at 400mA means we should only suck down 400mW there.

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

iEYEARECAAYFAkhp4woACgkQOjLpvpq7dMqoewCfds0gQCjGpT3O3SXvI5KB5mSP
phoAn12P7vXBJjBEqinod2k03SYb6wXL
=/920
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list