I’ve been looking at what the actual sleep current of the MSP430 will be when it’s running as an RTC.
Pin Leakage
The IO pin leakage needs to be taken into account when designing the gumsense. Just out of interest, I looked up the IO pin leakage for MSP430s and for PICs. The MSP430 has a pin leakage of 50nA per pin, whilst the PIC has a pin leakage of 1uA per pin. Yes, that is a factor of 20 different. Shocking!
However, if before going into sleep the IO pins are set to be outputs then this is avoided. Obviously, it’s not going to be possible to make all pins outputs, since the MSP430 may have a couple of edge triggered interrupts (e.g. gumsense wake up msp430 – for development purposes). The datasheet specs the sleep current for when all inputs are tied to VCC or VDD, so I’m not entirely sure when the leakage current applies. It’s probably when inputs are floating.
Current consumption
Two power modes of the MSP430 would be used in the gumstix: AM and LPM3 (see page 2-15 (32) of the “MSP430x1xx Family User’s Guide”). Looking at the datasheet for the MSP430F1611, the currents are:
- LPM3: 1.3 uA at 2.2V, 2.6 uA at 3V
- AM: 560uA at 3.3V at 1Mhz.
So, if the only reason for going for the MSP430 is the current consumption, the MSP430 must be run at the lowest voltage rail possible. The lowest that it can go is 1.8V. However, a couple of hurdles are introduced by doing this:
- It would require level translation between the gumstix and the gumsense.
- The MSP430 flash can only be reliably written when VCC is above 2.7V.
But what if I were to run the MSP430 at 3.3V? Would it be the end of the world? If the timer is supplied by a 220mAh CR2032 button cell, then using 3uA would give a lifetime of 8.3 years. That’s a fairly long time. Considering the battery itself would only be functional for 2-3 years, it’s probably not worth worrying about.
The advantages that the MSP430 brings to the gumsense are:
- Makes it cheaper (apparently this doesn’t matter so much, because this is a research project – but I’d like to think that it does) by reducing the component cost and count
- It’s programmable in C, with free stuff
- It’s trivial to connect the JTAG pins of the MSP430 to IO of the gumstix, so that it can be flashed in situ, without any additional development tools
- The MSP430 uses less current when operating at the same number of MIPS than the existing PIC.
- The MSP430 is 16-bit, and so the instructions do more stuff – so it would be running for shorter periods than the current PIC.
The second of those points I think is a biggy. If a researcher were to pick it up and wanted to change the code on the gumsense for some reason (e.g. they needed to change the scheduling, or make it run in a standalone mode), then they wouldn’t have to buy a programmer or compiler for the device.
I’ll investigate running the MSP430 at 1.8V during sleep and then switching to 3.3V during operation, or indeed perhaps only switching to 3.3V when it needs to write to flash (very rare. In fact, so rare that the ). I’ll basically look more into level translation when I know the levels involved. I guess the things that connect externally to the gumsense may need 5V signals.
Other things
My other thoughts involve how I can actually measure the real power consumption of the gumsense once i’ve got a prototype running. I’d like to be able to produce graphs of current versus time. This may be problematic because the current ranges from about 1uA to a couple of hundred mA.
An interesting TI application note is SLAA149B: “Programming a Flash-Based MSP430 Using the JTAG interface“. However, it just specs the programming interface, not the debug interface – i think it’s still necessary to use a proprietary binary blob to get that. Still, it works.
Site by Rob Gilton. © 2008 - 2019