-----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-----
