• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 122 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSPM0L2117: Clarification on current consumption estimation for RUN/HALT/STANDBY with LCD/RTC enabled

Conor
Guru 14700 points

Part Number: MSPM0L2117
Other Parts Discussed in Thread: ENERGYTRACE

Hi,

I would like to ask for clarification regarding current consumption estimation for MSPM0L211x under a low-power use case.

We are reviewing whether the device can meet the following customer requirements:

  • Product OFF state: 0.5 µA (standby)
  • Active state: 5 µA (run)
  • Clock assumption: 32 kHz

The intended operating conditions are as follows.

Case 1:

  • Timer/Counter 1: ON
  • Timer/Counter 2: ON
  • LCD driver: ON
  • Switch detection port: ON
  • RTC: ON
  • CPU: HALT

Case 2:

  • Timer/Counter 1: OFF
  • Timer/Counter 2: OFF
  • LCD driver: ON
  • Switch detection port: ON
  • RTC: ON
  • CPU: RUN + HALT

While reviewing the datasheet, we referred mainly to sections 7.5.1 RUN/SLEEP Modes and 7.5.2 STOP/STANDBY Modes.

Our current understanding is:

  1. In section 7.5.1, the RUN/SLEEP current values are specified under the condition that all peripherals are disabled.
  2. Therefore, the listed values cannot be directly applied to the above cases where LCD, RTC, and switch detection port are enabled.
  3. In section 7.5.2, STANDBY current is around 1.6 µA typ to 2.14 µA typ depending on the condition, so achieving 0.5 µA in standby already appears difficult from the published data.

However, we are unsure how to correctly interpret the RUN current at 32 kHz.

Initially, we considered estimating RUN current as:

  • IDDRUN, per MHz = 98 µA/MHz at 25°C typ
  • Therefore, 98 µA/MHz × 0.032 MHz = about 3.1 µA

But this result seems inconsistent with the SLEEP current shown in the same table:

  • IDDSLEEP, MCLK = LFCLK, CPU halted, 32 kHz = 266 µA typ at 25°C

A RUN current of about 3.1 µA and a HALT/SLEEP current of 266 µA at 32 kHz does not seem physically reasonable, so we suspect that this linear scaling approach is not valid.

Could you please clarify the following points?

  1. Is it correct that the 98 µA/MHz value should not be linearly scaled down to estimate RUN current at 32 kHz?
  2. For a 32 kHz operating condition, what is the correct way to estimate current in RUN state?
  3. For the above Case 2, where the CPU alternates between RUN and HALT, should the current be evaluated as an average current based on duty cycle rather than as a pure RUN current?
  4. For Case 1 and Case 2, is there any published or recommended method to estimate total current when LCD driver, RTC, and GPIO/switch detection are enabled?
  5. Based on your experience, does meeting the customer targets below seem feasible on MSPM0L211x?
    • 0.5 µA in standby
    • 5 µA in run/active condition at 32 kHz

If there are any recommended measurement conditions, example configurations, or application notes for estimating these low-power cases, we would greatly appreciate your guidance.

Thanks,

Conor

  • 0
    TI__Genius 12805 points

    Hi Conor,

    As per your questions:

    1. Yes, the parameter 98 µA/MHz value could not be linearly scaled down to estimate RUN current at 32 kHz. It is calculated from test running in 32MHz.

    2. The operation consumption in 32kHz should just be a little bit higher than parameter in SLEEP mode with LFCLK. But the actual power consumption should be got from a real test.

    3. The CPU running power consumption is much depends on the running frequency and the code executed. Generally a CPU operation power could be tested based on while loop. You could test based on a 50% duty in your case 2, but the duty cycle will do have impact on your final result.

    4. You may need to make a project based on your required peripherals and I think the most consumption will be contributed by LCD. And you could test with EnergyTrace tool if you have XDS110 debugger. You could check 3.6 of XDS110 Debug Probe for details of energy trace.

    5. For the first one, 0.5uA in standby, it could not be met by current device. But could you clarify whether the SRAM should be retain in this "standby" mode?