-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | On 8/20/08, Andy Green <[EMAIL PROTECTED]> wrote: |> We have no control over PMU startup. It brings up various rails how it |> likes all at the same time at levels it likes. | The PCF50633 ? | I have printed out the schematics but not committed them to memory yet.
Yes, but the datasheet does not have all the info. There are various mask-programmed options on our variant I don't know are listed anywhere externally. But the basic deal is it switches on a bunch of regulators all at the same moment with a high current limit pretty much guaranteeing major dip in the rail that supplies them, when that rail is fed from USB with a 500mA limit itself and the battery. If the battery isn't "there" enough to support the supply rail (or at all) then the system fails to start up even. |> Problems with startup at low battery (I guess the foot-tangling you |> mean) are caused by inrush current limiting also being set too high by |> PMU itself and again out of our control because the CPU does not come up |> until later. | foottangling: switching off functions and them staying on. no reaction on | LowerRight button but the TopLeft still works. And some issues when the | cpu seems to be idling busy ( tjouchschreen reacts with large delay ) Sounds like userspace world stuff. |> These are some of the reasons we would like an always-on MPU to manage |> PMU startup in a way we control from the start. | Would "reeducating" the PMU help? | ( Will read the complete DS later tonight ) | | uwe | (sorry if I have stepped on someones toes.) My toes are fine, I just see the makings of a new "LED driver current" problem here [1] and it needs explaining clearly and quickly before the lists get filled with "GTA02: testicle microwave in your pocket even when it is off?" If there's a real problem we have to know but equally if the problem is "unreal" or "theoretical-only" that needs pointing out too. Additionally some months ago various people in Openmoko did not understand these reasons to have an MPU to manage the system and rejected the idea. Since not having any "always-on intelligence" blew up in our faces with the low battery issue I guess it will have an easier ride next time. - -Andy [1] Previously LED driver had a problem it ate some tens of mA due to bad design when the LED was on. The LEDs are very seldom on, but there was all kinds of hysteria on user lists that went on for some time. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkisBjcACgkQOjLpvpq7dMr84QCeJVtZ8NFdOXQpTHWJcyXyqjj1 V58AoIo1l/At6TZZ9V1kebQe+LfjV3rH =Ctxj -----END PGP SIGNATURE----- _______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
