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.

MSP430G2433: ~REFON delaying entry to LPM3

Part Number: MSP430G2433

I have a program that samples for 50 ms on a 1 sec period (approximately). Uses LFO for timing and ADC10 for sampling.

50 ms -> sample continuously
950 ms -> stop sampling and enter LPM3 with timer running off LFO

When entering LPM3 at the end of each 50 ms sampling cycle, I run the following code:

// RFD sleep function
void SleepRFD(void) {
    ADC10CTL0 &= ~ENC;                      // Stop conversion
    ADC10CTL0 &= ~REFON;                    // Turn off reference

    RF_DET_OFF                              // Turn RF supply off
    ALL_LED_OFF                             // Turn LEDs off

    __bis_SR_register(LPM3_bits);           // Enter LPM3

If I turn the reference off (ADC10CTL0 &= ~REFON;), I get a good minimum Iq of about 0.012 mA, which is the parasitic draw of my circuit. However, I get very large amounts of delay entering LPM3, so the average current consumption of the overall code (sampling and sleeping) is 6.6 mA. See attached images for Energy Trace plot of this.

If I leave the reference ON (//ADC10CTL0 &= ~REFON;), I get a worse minimum Iq of about 0.194 mA, which is dominated by the reference current draw. However, the code enters LPM3 quickly, so the average current consumption of the overall code (sampling and sleeping) is 2.3 mA. See attached images for Energy Trace plot of this.

Looking at the energy trace plot, it looks like switching the reference off is causing a delay in the MSP430 entering LPM3. What should I be doing differently to power off so that I can shut off the reference and enter LPM3 quickly? Also, why does Energy Trace show a LONGER estimated battery life for the HIGHER mean current draw of the first trace?

  • Daniel:

    Without having the entire program to inspect, nor the overall objective, I think you are using the wrong programming approach.

    Try this one. Inside of main() setup the ADC so it will be ready for use when needed by an interrupt service routine (ISR), then setup a timer to trigger an ISR every 1 second, and then as the last instruction in main(), put the microcontroller in LPM3.

    Inside of the ISR, write instructions which activate the ADC, then use the ADC to capture a sample, then deactivate the ADC, and whatever else you need the microcontroller to do. When the CPU finishes with the ISR, it will automatically put the microcontroller back into LPM3.

    To get even lower power consumption, use LPM3.5, but that requires some additional instructions in main() right before you put it to sleep. It also cuts power to the ADC. But such a power mode forces a full reset from interruption and so you must use the RTC as a timer in that mode. Those instructions basically prepare the microcontroller for LMP3.5. Using this mode is mode complicated, but really lowers power consumption.

    Using that approach is really the most effective way to reduce unnecessary power consumption.

    I hope that helps.

  • Can you describe (or paste) your ADC10 configuration? I'm wondering if this has something to do with the fact that setting ENC=0 doesn't immediately stop an ongoing conversion [Ref UG (SLAU144J) Sec]. I wouldn't expect this to take 10s of ms in any case, but it's a place to start.

  • Hi Thomas,

    Thank you for the reply. An application description is at the bottom of this reply. Single ADC samples are not viable.

    What I am working on, is minimizing the LPM3 power consumption. That's "free" energy, and getting it down will not interfere with the performance of the device, which is sample rate driven.

    Upon further investigation, I have noticed that Energy Trace actually reports significantly less total energy consumption on the trace that shows the "lumpy" current draw and mean current of 6.6 mA. This leads me to believe that, within Energy Trace, the energy consumption integrator is probably working correctly, and the current measurement trace is probably working incorrectly. Going to verify with some test equipment in the coming days.

    Are there known bugs / limitations of this sort with Energy Trace? I typically do this testing with my lab equipment, but am working remote and have limited access to that, so leaning on TI's tools a little more here.

    Application Description:

    I need the full 200 ksps on the ADC during the 50 ms sampling window as I am sampling high speed modulated waveforms. I need representative "slices" of the waveform, from which I can make power measurement calculations. I do not need to sample them with 100% duty cycle in this application. 5% duty cycle is adequate. Lower duty cycle compromises measurement integrity. A single sample will fail to give a clear picture of the waveform peak amplitude or average signal power (integrated). There has to be a window of samples, it needs to be min 5%, and it needs to be sampled quickly. These are application driven requirements. This portion of the code, and its circuitry, are already power consumption optimized.

    MSP430G2433 does not have LPM3.5. I do use LPM4 with good results in appropriate system modes. Iq in these modes is 11 uA or less, which is the Iq of my supporting circuitry. The MSP430 is in the nA here.

    Thank you again for the reply. I appreciate you taking the time to comment on this. I hope that both the question put forth here, as well as the application requirements, have been made more clear.

  • I have found the problem. There is an unresolved bug in Energy Trace. See the following post:

    This is exactly the issue I am seeing, and a very similar design as well (switching power to an RF module). Same lumpy current trace and everything.

    When I use test equipment to measure my power consumption, it is correct (low) and those lumps on the current trace are not there. The MSP is switching correctly (and quickly) into LPM3. In my case, the energy consumption value from Energy Trace is correct, but the current measurement and trace is incorrect. Makes perfect sense from the detailed analysis of the bug in the above TI forum post.

    There are other posts reporting this bug, going back a few years. Hopefully it can be resolved. Until then, it may be helpful to more widely inform users of this issue so they can use other tools during system development.

  • Thanks for your sharing!