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.

Too high power consumption on MSP430FR5739

Other Parts Discussed in Thread: MSP430FR5739, ENERGYTRACE, MSP-FET, MSP-TS430RHA40A, MSP430FR5969, MSP430FR2033

Hi.

I have an MSP430FR5739 + target board + MSP-FET Flash Emulation Tool (with EnergyTrace). I am trying to reduce the power consumption down to Active Mode: 81.4 µA/MHz (Typical) which is specified in the datasheet http://www.ti.com/lit/ds/symlink/msp430fr5739.pdf, but the MCU is consuming more than expected (typically around 270 µA) on default clock speed, and also tried lower frequencies and low power mode as well, but all consumption measurements are significant higher than values "promised" by the datasheet. Consumtion is measured using MSP-FET Flash Emulation Tool (with EnergyTrace) on target board MSP-TS430RHA40A (Rev. 1.0).

I have disabled the internal temperature sensor and set all GPIO ports to output and reset them.

Are there any hidden current consumption from the target board?

Can you please help?

  • What are the markings on the chip? Did you check the Errata?
  • Hi,

    I took a look in the datasheet, and your power number matches the datasheet specification for 1MHz operation. If you look in the datasheet www.ti.com/lit/gpn/msp430fr5739 in section 5.4 Active Mode Supply Current into Vcc Excluding External Current, you'll see that it lists TYP current for 1MHz with ~66% cache hit ratio (which is a pretty typical application cache hit ratio) as 0.27mA. That is 270uA, exactly what you are seeing. This chart provides much more detailed information about current consumption than the 1 line highlight on the front page, so that you can better predict what you will see under your application's particular set of conditions.

    So why does 81.4 uA/MHz not mean 81uA at 1MHz? The current consumption is not linear with MHz operation, so the front page has to show something more like what a typical application might see (which is why it is marked "Typical" on the front page) - but of course it can depend greatly on the operating frequency you use (which part of the curve of uA/MHz it is in) and what cache hit ratio your code has. For example, if you look in the same section 5.4 at 8MHz with 66% cache hit ratio (CHR), that is 0.58mA so 580uA/8MHz = 72.5uA/MHz which is better than the number on the front page - if you have a better cache hit ratio you can also see even better numbers. At 24MHz with 66% CHR you can calculate it is 91.6uA/MHz, still pretty close to that front page number even though you are running at the max speed of the part. 1MHz is actually kind of the worst case point if you look purely at uA/MHz.

    For calculating the current budget in your application, instead you may want to plot in a spreadsheet the uA and MHz for some different points, as well as taking into account the duty cycle of awake vs LPM mode in your application. This can help you to find the "sweet spot" in terms of operating frequency to get the best current consumption for your particular use-case. For example, if you will do x instructions in active mode (to accomplish a certain task) once a second, and will be in LPM3 the rest of the time, your current numbers could look like this: (I assumed a 66% cache hit ratio for all of these, took wake time from LPM3, LPM3 current, and active mode currents at different frequencies all from the datasheet).

    100 instr. triggering 1/sec
    MHz # instructions Active (s) uA (Active) wake (s) LPM3 (s) uA (LPM3) uA (Avg)
    1 100 0.0001 270 7.80E-05 0.99982 6.3 6.3469
    4 100 3E-05 580 7.80E-05 0.9999 6.3 6.3591
    8 100 1E-05 1000 7.80E-05 0.99991 6.3 6.3899
    16 100 6E-06 1550 7.80E-05 0.99992 6.3 6.4301
    20 100 5E-06 1900 7.80E-05 0.99992 6.3 6.4572
    24 100 4E-06 2200 7.80E-05 0.99992 6.3 6.4802
    1000 instr. triggering 1/sec
    MHz # instructions Active (s) uA (Active) wake (s) LPM3 (s) uA (LPM3) uA (Avg)
    1 1000 0.001 270 7.80E-05 0.99892 6.3 6.5843
    4 1000 0.0003 580 7.80E-05 0.99967 6.3 6.4882
    8 1000 0.0001 1000 7.80E-05 0.9998 6.3 6.5017
    16 1000 6E-05 1550 7.80E-05 0.99986 6.3 6.5169
    20 1000 5E-05 1900 7.80E-05 0.99987 6.3 6.5424
    24 1000 4E-05 2200 7.80E-05 0.99988 6.3 6.5625

    You can see that the average current depends on a number of factors then, and that in this back-of-the-envelope calculation that for 100 instructions 1/sec, it is better to run at 1MHz, but for 1000 instructions/sec it is better to run at 4MHz. Basically, it depends on how long you are going to be awake vs asleep to see if the incremental current increase of a higher frequency is worth it or not, and trying to find the best tradeoff to find your operating point for your app.

    I hope this helps to give some insight.

    Regards,

    Katie

  • One important thing I forgot to mention: this is also the beauty of EnergyTrace - it lets you quickly build your code at different clock frequencies, run it, and do a comparison. Then you can find the "sweet spot" for current vs clock frequency in your actual application, without having to make all of these assumptions (cache hit ratio, wake current, also not accounting for any modules on or anything) like I had to do in my calculation above - it will give you actual numbers.

    -Katie
  • Thank you for a valuable answer! We are working with a solution that are totally dependent on low power consumption and a small startup time. We are trying to configure the DCO (MCLK) to use VLOCLK (10 kHz) in combination with LPM3 + GIE, but we get a MCU startup time which is to long, about 30-40 ms when we configure the clocks. Below is our current code snippet for clock setup.

    CSCTL0_H = 0xA5; // Unlock register
    CSCTL1 |= 0; // Set min. DCO setting
    CSCTL2 = SELA_1 + SELS_2 + SELM_1; // set ACLK = vlo; SMCLK = vlo; MCLK = vlo
    __bis_SR_register(SCG0 + SCG1); // disable DCO and FLL
    CSCTL3 = DIVA_0 + DIVS_0 + DIVM_0; // set all dividers
    CSCTL0_H = 0x01; // Lock Register

    Our requirement for startup time is < 1.5ms, for instance 1ms. Is it possible? Can we do anything different? Any other controller we can use to achieve it?
  • What is the purpose of setting MCLK to run off of the VLO instead of the DCO? That means that your main CPU clock will only be running code at ~8kHz. Is that really wanted? The DCO will turn off when you enter LPM3 anyway and only VLO (if you have it sourcing ACLK) would stay on.

    In addition, I see the line __bis_SR_register(SCG0 + SCG1) - I don't think that it's really recommended to set these two bits outside of going to LPM. What is the purpose of this line in your case?

    30ms is far longer than the ~78-120us wakeup time from LPM3 specified in the datasheet, so I think something must be wrong in this case - this is why I'm wondering about these details of your setup. If you run the LPM3 example code here: dev.ti.com/.../ and modify it to wake from a GPIO, what wakeup time do you see? You could measure the time from the GPIO edge that should wake the part, to the MCLK starting up.

    Regards,
    Katie
  • Thank you for answering again :)

    What we want is small power consumption, therefore the setup of MCLK to VLO, but I see your points. The critical part of our solution is the actual startup time and power consumption on power up, and not wakeup time from LPM3. I believe wakeup time is much smaller than startup time on first power up.

    A short description of our use case:

    • The MCU get power on for about 1.5 ms.
    • Within the time frame of 1.5 ms we need to read a state from stored in FRAM, write to a GPIO pin, store new state to FRAM and then enter LPM3.
    • We also tried to do setup of the clock network as shown in the code snipped within the time frame of 1.5 ms, but without success, as mentioned.
    • After going into LPM3 an interrupt timer will wake up the MCU in order to repeat the same procedure.

    The purpose of __bis_SR_register(SCG0 + SCG1) was to disable the DCO and FLL, but it doesn't seem to be affected anyway, so I removed it.

  • Startup from unpowered is difficult - if you are totally unpowered, the device will take longer to startup than it does when you simply wake from LPM - booting the part from nothing takes a lot more time than simply waking up. If you look in the datasheet at the section 5.19 Wake-Up from Low Power modes, if you are coming up from being off you're going to at least be seeing the time twake-up BOR which is listed at typical 1.6ms. Contrasted with wake from LPM3 which is much shorter.

    So is this application needing to be entirely powered down between cycles - do you only get 1.5ms of Vcc periodically and have to get everything done in that time, completely powered down in between? How long is it between these 1.5ms bursts of Vcc? Can you tell more about what type of application this is?

    The reason I'm asking these is that I think the timing will work out better for you if you'd be able to stay in LPM3 or LPM4 between these pulses - so basically (depending on timing) having a supercap or small battery that can be used in between these voltage pulses to simply let the part be asleep in LPM3 or 4 during this time - that way the startup time will be much shorter.

    I also wanted to note, for that type of application I believe that MSP430FR5969 may be a better choice - it has a much shorter wake time from LPM3 or 4 (only 7-10us), and it also has lower current while in LPM3 or 4 (~0.5uA - see datasheet). The MSP430FR5969 is more optimized to have better LPM current whereas the MSP430FR5739 is more optimized to have better active current. If you're in LPM for very much of the life of your device, MSP430FR5969 is probably a lower power option. Note that the startup time from unpowered is similar between the two parts.
     
    Regards,
    Katie

  • Ok. It is a power harvest application, and we only have small pulses with energy (1.5 ms) on a 400-500 ms interval, and we are not able to use battery or supercap in our solution and we does not seem to have enough energy to keep the MCU in LPM3 or 4 until we get the next pulse. Anyway, thank you for your suggestions.

    Another question; what controller have the lowest power consumption during startup, but still the same startup time (BOR) around 1.6 ms? Does it exist any controller that have the option to disable the BOR before startup from nothing via fuses or so. Any other suggestions?

  • I tried checking the F2xx family of parts, but these seem to similarly have a td(BOR) spec of 2000us (and they're flash based which means your non-volatile writes would take more current).

    For the smaller FR2xx FRAM parts like MSP430FR2033, which also have a very low current consumption, it looks like they have a 1ms startup (BOR) time so that would be slightly better (but maybe too tight for your purposes?). This would still have FRAM for your non-volatile writes which should help in your situation.

    For disabling BOR - that's not really something you can do (nor would want to do) in that the BOR keeps the part from running before the voltage has reached a sufficient level for the part to actually run correctly and not have errors. That being said, I think some of the old F1xx didn't have a BOR, but then you'd have to have some sort of external supervision I think because the part still has a minimum voltage spec at which it can run safely and you don't want it to run before that.

    Regards,
    Katie

**Attention** This is a public forum