next-generation (now) MPU discussion / Backup battery on PMU only

[Andy Green]

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