next-generation PMU discussion / Memory 1.8V

joerg at openmoko.org joerg at openmoko.org
Mon Apr 21 11:44:40 CEST 2008


Am Mo  21. April 2008 schrieb joerg at openmoko.org:
> > 
> > We didn't settle on NXP (at least I didn't hear Tony say anything) but I
> > don't think we can burden the core design with new chips and so on to
> > solve this.  And I'm not sure about series diodes.
> 
> Well we probably don't save much power with sophisticated power design for 
> MPU. The idea with a Schottky for feeding the (now) 1.8V to MPU isn't that 
> good either. But was only to save another FET. Probably we should hook the 
> 430 up to Vbat with a lowdrop-linear-regulator. Still wondering about 
> Vbackup...
> 
> 
> > 
> > Correct me if I am wrong, but doesn't VSYS see USB power, ie, 5V?  We
> > can't use that directly if so.
> 
> ? more on this later
> 
> 
> > 
> > There is a 1.8V in standby because the memory takes it, we can use that.
> > ~ When we need 2.2V not sure what the story should be.
> 
> 
> Don't we need the 2.2 for flashing the ROM?

According to datasheet [MSP430x15x, x16x, x161x]:
AMR: 
   Vcc to Vss -0.3 to 4.1V
recommended:
   during execution: 1.8V to 3.6V
   during flash: 2.7V(!!) to 3.6V

I'd say it's NOT recommended to operate the device at minimum Vcc, 
because: "The minimum operating voltage is defined according to the trippoint 
where PowerOnReset".. is going to fire. It safely stops when "raising above 
min supply voltage PLUS hysteresis of SVS circuitry..." Wahtever this 
SVS-hyst may be...

8MHz operation requires VccMAX if I understand this diagram correctly. At 1.8V 
there is 4.15MHz max speed.

I think it's absolutely worthless to think about the powerconsumption in MPU 
active state, assuming we are 99,9% of the time in suspend waiting for an 
interupt, and we could run nearly or more than 1000h(!) even on full speed. 
Is there any use in extending standby time from 100.000h to 1.000.000h (for 
MPU power consumption, not for whole device) ???

/jOERG




More information about the openmoko-kernel mailing list