Jump to content

reduce startup time on MSP430FR5739

Recommended Posts


I have a real short program which runs on a MSP430FR5739. I have just a short impuls of energy to start the MC and write to the FRAM. The problem is that the amount of energy is nearly enough. At the actual programm, the MC needs 98% to start and 2% to execute the program.


So is there any posibility to reduce the startupt time? My Programm is not time critical or something...


Thanks for your help




PS: Is my first MSP430 Project...



#include <msp430.h>


#pragma SET_DATA_SECTION(".fram_vars")

long umdrehung;

Link to post
Share on other sites

I'm not really familiar with the FRAM parts, but I do know that usually variable definition will also do initialisation. By using the no init attribute you can force the compiler to do no initialisation.

__no_init volatile unsigned int i;

Also, changing DCO frequency may take a fair amount of time to become stable. If it is acceptable, try not to change it.


If you have any variables that not need to be global, try moving them further toward the point where they are used (any static variable is considered to be global in scope), preferably until after changing the clock frequencies; initialisation and stack allocation will then be postponed to when the device is in "high speed".

As a last tip, if you ever have a significant delay (say, over 50 cycles) you should consider using a timer instead and switch to low power mode.

Link to post
Share on other sites
thanks alot for your answer


i tried your suggestion, with the variables change to not global i could speed up from 1.92ms to now 1.31ms thats cool. many thanks.


If i comment

 CSCTL0_H = 0xA5;

 CSCTL1 |= DCOFSEL0 + DCOFSEL1;             // Set max. DCO setting

 CSCTL2 = SELA_3 + SELS_3 + SELM_3;        // set ACLK = MCLK = DCO

 CSCTL3 = DIVA_0 + DIVS_0 + DIVM_0;        // set all dividers

it haven't influence of the startup time. (i mean the time from power on to the first action in the while loop)


The idea with the delays is great, but at the moment i like to try to reduce the start up time.


Is ther any posibilitis to deactivate all these hardware stuff which i not use? to reduce the 1.31ms again? thad would be great.


Thank alot.


Link to post
Share on other sites

How are you measuring the startup time?  You might need to hack into the startup code to have it toggle a GPIO before doing anything else, then measure the delay from power-on to that point, and that-point to "done", with a logic analyzer or oscilloscope.  1.31 ms seems like a long time, and if it's all in analog circuitry before the MCU starts executing there may not be much you can do about it.


The MSP430FR5739 data sheet seems to have very little information about current usage, LPM wake-up times, etc. compare to other MCUs like the MSP430F5438.  Without that information you can't determine what a realistic startup delay would be.

Link to post
Share on other sites
thanks for your answer, yes that's maybe my fault, startup time is probably not the right description. i measure the time between the rising edge of the VCC and the edge of the first C command.


It would cool if i could deactivate the RTC or all the other stuff.


Existing on the MSP430 also "fusebits" like on a avr MC? How can i change this?




Link to post
Share on other sites

Most of the peripherals are disabled on startup; if you aren't enabling them, there's no need to disable them.  My point remains: you need to know how that 1.3ms breaks down.  There are several events of interest:


1) Apply power

2) MCU starts executing boot code;

3) MCU starts executing code at the reset address;

4) MCU passes control to your main() routine;

5) Reach the start of the while loop.


When P2.2 goes high after you configure the clocks is a good estimate of point 4.  Figuring out how to do something similar at point 3 depends on your toolchain; for mspgcc it'd involve inserting some custom code into the startup sequence; there's probably something like that for IAR and CCS too.  Absent other evidence I expect the time between events 2 and 3 to be extremely small (loads calibration constants from somewhere and looks for a BSL sequence).


I'd worry that the bulk of the time is between events 1 and 2 (e.g., hardware waiting for DCO or other stuff to stabilize), and that there's nothing you can do in software about it.  Are you using the EXP430FR5739 "Fraunchpad" or some other board?  How are you supplying power to it?  Is the USB plugged in to a PC?  Are you doing the timing while it's controlled by a debugger?  All these could be relevant.


I don't really have any other suggestions.

Link to post
Share on other sites

If you really need to strip off more time, you could alter the startup code, but I do not recommend fiddling so deep in the system.

I'm not sure about the FR series, but the F and G series have only a single fuse; to disable serial programming/debugging.


A little more on variables:

int a; // I get initialised by the startup code
int b = 1; // I get initialised by the startup code, AND a memcpy() will be called to fill me and any other non-zero global variable
_no_init int c; // I get allocated, but not initialised; allocation of static space is just a single assignment to the stack pointer for all global variables

void foo(void){
  int d; // I get initialised at the entrance of main() (just before in most cases, could be just after in C++ cases)
  bar(); // I get called after initialisation of 'd' and 'e'
  int e; // C99 allows variables to not be at the start of a scope, they will still be allocated (and initialised?) at the start of the scope
    int f; // Since f is in a new scope, it will be initialised at the start of this new scope; after the call to bar()
Link to post
Share on other sites

It looks like you are using the DCO.  Instead, you could get a crystal that starts-up faster.  Use an 8MHz crystal, for example, and disable DCO or FLL or anything like that.  Those things have long startup times.  In fact, you should use the highest crystal you can, with low capacitance, and then divide it to 8MHz if you want to get the absolute fastest startup time.


Is this an EnOcean project?


Edit: I'm looking at the Users' Guide

- There is little to no information about how long the startup-time is for the DCO.

- It seems that the DCO is the HW default for startup.  Don't change it, that will slow you down.

- MSP430 clock systems tend to be slow to stabilize.  You may just be stuck with slow startup.


One thing you can do is to measure the time between startup (voltage on) and the first line of code.  That line of code is accessible with the assembly output, you can set a pin to high first-thing.  Then you will find how long the PUC takes to provide a suitable clock to the MCU for startup.  If it is too long, then you can always find another controller and perhaps use an external FRAM or MRAM chip.

Link to post
Share on other sites
One thing you can do is to measure the time between startup (voltage on) and the first line of code.  That line of code is accessible with the assembly output, you can set a pin to high first-thing.  Then you will find how long the PUC takes to provide a suitable clock to the MCU for startup.


Which is pretty much what I've said twice now; perhaps I've been too verbose and this restatement will clarify things.

Link to post
Share on other sites
@all: thanks alot for your effort to help. I am really glad about your tips. Thanks


The tests today, with the reduction of 1.3ms, seems to be quite good. So hopefully or probably I do not need to reduce it more.


@pabigot: Tanks for yor details answer. Good to know. To your question: yes i am using the EXP430FR5739 "Fraunchpad".

I supplying the bord with a frequenzy generator on a low frequenzy and measure with a oscilloscope the time between the edge form the generater and the PIN2.2.

All jumpers and USB are unplugged.


@rockets4kids: I can't use the sleep mode because i can't garantee the power supply between the next Energy inpulse. For example: It could be a delay for about 10 years.

And a battery is not allowed..


@roadrunner84: Thanks for your imput, maybe i try this option if the next tests are negativ. But hopefully not.  :-)

Thanks for the input with the variable.


@jpnorair: thanks, yes i thought also about an other MC with extern FRAM but if it would work with the MSP430 it would be better...


It is not en EnOcean project but quite similar.


Thanks at all. Manuel

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...