-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | Andy Green wrote: |> What is the downside if MPU is down during this time? | | I can think of the following two things: | | - it can't be part of the decision of when we power up. I.e., we | couldn't assign POWER to a different button or such. | | Not sure if we care about this point.
I don't think it matters. | - there are some signals that need to have a specific state also when | the CPU is not powered or when it is in CPU reset, e.g.: | | - anything that controls power and wakeup of items directly connected | to the battery or to Vsys | | - the USB pull-up | | Our current solution is to use discrete logic and the (very few) GPIOs | of the PMU. One problem with the PMU's GPIOs is that they may not | default to the state we need in the end, so this adds more glue logic | and possibly pull-ups. | | While discrete glue logic is cheap on the board, it also has a high | engineering cost if we need to spin a new layout just to test some | slight change. We've been there before. I think this is a separate issue... we need to design these individual elements that cross power domains to act safely (logically) at all voltages on other other power domain. If the battery backup is exhausted then it didn't help anyway compared to the MSP430 not having any at all: both ways the MSP430 comes up from dead and we still need to work in that case too. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgRv20ACgkQOjLpvpq7dMroAQCePIhIomvwfF8eQVxi3WKutt4n yP8An3zQ7qtnMrOaED7LrUH69eRghObD =posZ -----END PGP SIGNATURE----- _______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
