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

Andy Green andy at
Fri Apr 25 13:24:29 CEST 2008

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
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the hardware mailing list