This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP-EXP430FR5994 LPM+EnergyTrace

Other Parts Discussed in Thread: ENERGYTRACE, MSPDRIVERLIB

I've been working with the EXP430FR5994 launchpad trying to learn the implementation of the LPM modes and obtaining the lowest possible current draw/consumption possible. This is my basic setup and operating loop code:

#include <msp430.h> 
#include <driverlib.h>


void initGPIO(void);
void initClocks(void);


#define greenLED 		GPIO_PIN1
#define redLED			GPIO_PIN0
#define LEDPort			GPIO_PORT_P1
#define pushButton1		GPIO_PIN5
#define	pushButton2		GPIO_PIN6

#define	LF_CRYSTAL_FREQUENCY_IN_HZ	32768
#define HF_CRYSTAL_FREQUENCY_IN_HZ	0


uint32_t myACLK = 0;
uint32_t mySMCLK = 0;
uint32_t myMCLK = 0;
/*
 *
 * main.c
 */
int main(void)
{
	WDT_A_hold(WDT_A_BASE);

//Initialization routines
    initGPIO();
    initClocks();

    RTC_C_holdClock(RTC_C_BASE);

    PMM_turnOffRegulator(); //controls LPM.5 mode
    PMM_disableSVSH();

    while(1)
    {
    	_low_power_mode_4(); //Enter Low Power Mode
    }

}

void initClocks(void)
{
	//set the crystal frequencies attached to the LFXT and HFXT oscillator pins
	//so that driverlib knows how fast they are (needed for the clock 'get' functions)
	CS_setExternalClockSource(
			LF_CRYSTAL_FREQUENCY_IN_HZ,
			HF_CRYSTAL_FREQUENCY_IN_HZ
			);


	//Configure Clocks
	//Set ACLK to us VLO as its oscillator source (~10kHz)
	CS_initClockSignal(
			CS_ACLK,				//Clock we're configuring
			CS_VLOCLK_SELECT,		//Clock source
			CS_CLOCK_DIVIDER_1		//clock divider
			);

	CS_turnOffSMCLK();

	//Set the MCLK to use the VLO clock
	CS_initClockSignal(
				CS_MCLK,				//Clock we're configuring
				CS_VLOCLK_SELECT,		//Clock source
				CS_CLOCK_DIVIDER_1		//clock divider
				);



}

void initGPIO(void)
{

#define GPIO_ALL        GPIO_PIN0|GPIO_PIN1|GPIO_PIN2|GPIO_PIN3|  \
                        GPIO_PIN4|GPIO_PIN5|GPIO_PIN6|GPIO_PIN7

	//set unused pins
/*
	GPIO_setOutputLowOnPin(GPIO_PORT_P1, GPIO_ALL);
	GPIO_setOutputLowOnPin(GPIO_PORT_P2, GPIO_ALL);
	GPIO_setOutputLowOnPin(GPIO_PORT_P3, GPIO_ALL);
	GPIO_setOutputLowOnPin(GPIO_PORT_P4, GPIO_ALL);
	GPIO_setOutputLowOnPin(GPIO_PORT_P5, GPIO_ALL);
	GPIO_setOutputLowOnPin(GPIO_PORT_P6, GPIO_ALL);
	GPIO_setOutputLowOnPin(GPIO_PORT_P7, GPIO_ALL);
	GPIO_setOutputLowOnPin(GPIO_PORT_P8, GPIO_ALL);
	GPIO_setOutputLowOnPin(GPIO_PORT_PA, GPIO_ALL);
	GPIO_setOutputLowOnPin(GPIO_PORT_PB, GPIO_ALL);
	GPIO_setOutputLowOnPin(GPIO_PORT_PC, GPIO_ALL);
	GPIO_setOutputLowOnPin(GPIO_PORT_PD, GPIO_ALL);
	GPIO_setOutputLowOnPin(GPIO_PORT_PJ, GPIO_ALL);
	PMM_unlockLPM5();
*/

	GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_P1, GPIO_ALL);
	GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_P2, GPIO_ALL);
	GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_P3, GPIO_ALL);
	GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_P4, GPIO_ALL);
	GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_P5, GPIO_ALL);
	GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_P6, GPIO_ALL);
	GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_P7, GPIO_ALL);
	GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_P8, GPIO_ALL);
	GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_PA, GPIO_ALL);
	GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_PB, GPIO_ALL);
	GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_PC, GPIO_ALL);
	GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_PD, GPIO_ALL);
	GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_PJ, GPIO_ALL);
		PMM_unlockLPM5();
}

At first I was having trouble getting the hardware to go anything below ~480uA in LMP3, 4 or LPM .5 and there wasn't any change in current consumption when changing between these modes with this code. At first I suspected that I just didn't have everything set right and so I went in register by register to confirm that the register bit fields were set according to the datasheet. They were, so I began to suspect a hardware issue. At which point I started pulling jumpers off of the Launchpad board to see what would happen. I now have J7, J101.5V, J101.RXD, and J101.TXD all removed and with this configuration running the above code it's down to ~70uA of current consumption measured by the EnergyTrace.  Based on this I'm wondering how much the hardware platform is getting in the way of achieving values closer to the listed datasheet values or how much of it is still me missing some initialization step which turns off some X module?

I also want to point out that in the code segment you can see that instead of setting the pins as output the pins are set as inputs with pulldown resistors. This is not very intuitive since it's counter to the documentation's recommendations to set unused pins as output. If I set pins back to output only, the current draw goes up to ~200uA. Footnote on Page 31 of the datasheet referencing LPM current draw tests

(1) All inputs are tied to 0 V or to V
. Outputs do not source or sink any current.

If outputs do not source or sink any current, what explains the difference in my own testing?

  • Using your code with the MSP-EXP430F5529 under the same jumper configuration, SD card disconnected, and Free Run mode to disconnect debugger operation, I was able to measure an average of 5.7 uA over a sample period of 1 minute. Seeing as how you do not use the LF XTAL, inserting CS_turnOffLFXT(); dropped the current consumption to the expected nAs range which are too low to be read by EnergyTrace. At this point you will need a highly-precise DC power analyzer to measure LPM4.5 numbers.

    e2e.ti.com/.../436304
    e2e.ti.com/.../434975
    e2e.ti.com/.../413579

    Regards,
    Ryan
  • Thanks for the feedback Ryan. I'll give what you suggest a try and see what I end up with.
  • I don't have that function call in my Driverlib cs.h file. All that's provided is the CS_turnOnLFXT() call. I'm running the 2.80.0.01 version of the Driverlib (both the IDE and Target Content).
  • I highly recommend upgrading your DriverLib version, the one you are using has several bugs which will cause issues for your application's development. CS_turnOffLFXT(); simply sets the CSKEY in CSCTL0 to unlock CS control, sets the LFXTOFF bit in CSCTL4, and re-locks the CS control by writing 0x00 to CSCTL0_H.

    Regards,
    Ryan
  • Do I need to re-download MSPWare everytime to keep things updated? The driverlib specific page (software-dl.ti.com/.../index_FDS.html) just downloads the 2.80.0.01 version, so it doesn't look like it's as actively updated.

    Also, the LFXT register bit in my code example is already set to be off anyway. I was inserting some code, as you suggested to turn off the LXFT via the CSCTL4 register but CCS reports that the LFXTOFF register bit is already set to 1.
  • Apologies Kevin, I was confused between MSPWare and MSPDRIVERLIB version numbers. You have the most up-to-date version but CS_turnOffLFXT() still exists in v2.80 according to the User's Guide. What current measurements are you now reading?

    Regards,
    Ryan
  • No worries. It did send me down a bit of a rabbit hole as I couldn't get CCS to do any updates (obvious now) so I uninstalled MSPWare and reinstalled it just to brute force it. It finally picked up the CS_turnOffLFXT() call and in free run mode I'm somewhere down in the 300 nA range. I'm right at the edge of my multimeter's ability to detect that low of a current but I verified it was in that range by turning the LFXT back on and the current went back up as expected. I think the biggest difference in this regard was being able to run the debugger in Free Run mode, which is a feature I wasn't familiar with before. Thanks for the assistance, I appreciate it.

**Attention** This is a public forum