next-generation (now) MPU discussion / Backup battery on PMU only
andy at openmoko.com
Fri Apr 25 13:24:29 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the hardware