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.

CCS/MSP430FR2311: Start-Up time with simple pin toggle

Part Number: MSP430FR2311

Tool/software: Code Composer Studio

Hi everyone,

I have a simple question about my MSP430FR2311 Devkit. Here is my code:

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

unsigned char i = 0;

int main(void)
{
   WDTCTL = WDTPW | WDTHOLD;               // Stop watchdog timer

   P1DIR |= BIT0 | BIT1 | BIT2;

   PM5CTL0 &= ~LOCKLPM5;

   P1OUT |= BIT1 | BIT2;

   for(i = 0; i<10; i++)
   {
       P1OUT &= ~BIT0;
       __delay_cycles(50000);
       P1OUT |= BIT0;
       __delay_cycles(50000);
    }
}

I checked the start-up time of the MCU by measuring the time between power on and rising of P1.1 and P1.2. 

It is 1.14ms WITH the for-loop and more than 2ms WITHOUT the for-loop. When I put more code (no mather what) below the for-loop, this time gets even higher.

This does no sense to me because this code is after the pin toggling... Is there something I have forgot or can anyone explain my that behaviour? I can post some pictures of my measurements if needed.

Thank you very much!

Regards,

Manuel

  • Hello,

    It is difficult to predict how the compiler is going to optimize the code when it is programmed into program memory. It is rather strange that removing the "for" loop causes the code to take longer to see a rise on P1.1. How are you measuring this delay time? Are you measuring the voltage directly on the VCC line and the voltage on P1.1 or are you measuring the time after a reset is triggered?

    Might I also ask, what is the purpose of determining the startup time with and without the for loop? Is there a specific requirement you are trying to meet?

    Best regards,

    Matt Calvo
  • Hi Matt

    Thank you for your answer. I used an Agilent poweranalyzer N6705B for that measurement. I measured the time between rising of VCC (3V) and rising of the pin.

    Yes, it is very important to have this time as short as possible. It is used in a very low-power system, in which every uJ I can save is very important.

    Regards,

    Manuel

  • Manuel,

    As I said, it is very hard to predict what the compiler is doing with your code when it is written to program memory. We can only suggest coding best practice strategies and one thing I could suggest is to try and go into low power mode at the end of your main function or include a while(1) loop at the end. Perhaps the undefined state currently at the end of your code is causing this phenomena.

    When you say that more code causes the delay time to increase makes sense because more code will lead to the initialization code to increase before the main function is ran. If your solution is power sensitive then your best bet is for your code to operate in an LPM state as much as it can.

    Best regards,

    Matt
  • Hi Matt

    Again, thank you for your answer.

    It really seems that more code needs to be initialized. I do not fully understand those FRAM microcontrollers yet but I've never seen this problem by using other (not FRAM) microcontrollers. So I think it should be possible to remove that additional time by changing things in boot code or something like that.

    I have not managed to change entry-point yet.  I know default is _c_int00 but in this project, the function _c_int00_noargs_noexit is used as entry point. How can I switch that to another function of that boot_special,c file? Or how can I write my own function? Seems like this is all precompiled in a library. I usually don't work that "deep" in the linker but it would be great to check if I can get the most efficient startup that is possible.

    I have a while(1) loop at the end of my code and of course I use LPM state as much as I can.

    Regards,

    Manuel

  • Edit:

    I just ported my firmware to IAR and I have no such delays in startup!
    It would be nice to get the same behaviour in CCS because of the licence in IAR.

    Regards,
    Manuel
  • Manuel,

    Could you provide the .map files generated for the code with and without the "for" loop. The .map files could reveal more about the startup code being included in the project by the run-time support library.

    -Matt
  • Hi Matt,

    Here again the code I used:

    #include <msp430.h>
    #include <driverlib.h>
    
    unsigned char i = 0;
    
    int main(void)
    {
       WDTCTL = WDTPW | WDTHOLD;               // Stop watchdog timer
    
       P1DIR |= BIT0;
       P1OUT |= BIT0;
    
       PM5CTL0 &= ~LOCKLPM5;
    
       __delay_cycles(50000);
    
       for(i = 0; i<10; i++)
       {
           P1OUT &= ~BIT0;
           __delay_cycles(50000);
           P1OUT |= BIT0;
           __delay_cycles(50000);
        }
       
       while(1);
    }

    And here are my .map files. Seems like CCS is choosing the custom _c_int00 function automatically...

    mapFiles.zip

  • Manuel,

    I just used your code from the first post in order to recreate your findings and was unable to. I created a new project for MSP430FR2311 and copied your code into the main.c file. I then measured the time from the rise of VCC to the rise of P1.2 and found that the delay was larger when the "for" loop was included. This makes sense because there are more values to initialize in memory.

    The delay without the "for" loop was measured to be 1.247ms and the delay with the for loop was measured to be 1.5ms. I also had my compiler optimized for speed inside of the project properties. I've attached the screenshots and my .map files for reference.

    Start-Up Info.zip

  • Hi Matt

    Thank you for your effort! You just wrote, you were unable to recreate my findings but you exactly recreated this delay. This is exactly my problem. In this example it's a very short delay so you may think, why I care about that... In my bigger firmware, which is mainly SPI communication and pin-toggling, this delay is moren than 5ms. In this time, I loose several microjoules!

    In IAR with the same firmware, this delay is just 1.5ms. And it won't go higher with more or less code. I stepped through the assembler code in IAR and there is nothing to be done before jumping to main address while CCS has those customized _c_int00 functions which I can't change. So it should also be possible with CCS to turn off those funtions. That would be nice, because I like it more than IAR :)

    I hope, it's a little bit clearer now.

    Regards,

    Manuel

  • Manuel,

    When I said I couldn't recreate the problem from the first post, I'm referencing that you stated there was a larger delay for the code without the "for" loop. On my end the, the code with the "for" loop had the larger delay.

    Regardless of what I'm seeing for the small code, your issue is with the ~5ms delay you are seeing with the larger code. I can try to recreate that and see what can be done about decreasing it if you send me your larger code.

    Best regards,

    Matt Calvo
  • Hi Matt,

    That was my fault!! I messed up those two delays. Of course it's longer WITH the for loop. I'm sorry but I can't provide the code because it's confidential. I try to make a new similar project without the confidential things these days...

    Or maybe someone can explain me how to take influence on startup procedure...


    Thanks and regards,

    Manuel

  • Manuel,

    That's understandable! For your similar project file, be sure to have dummy variables/arrays and a code flow that is similar to your confidential code that way I can try to recreate the large delay you are seeing.

    Best regards,

    Matt Calvo
  • Hi Matt,

    Here is my project that I just created. Same stucture and same amount of variables.

    Time from VCC until rising of P1.2 and P1.4 is 5.3ms. When I delete the switch instruction in main, this time is just 4ms. Just because of a switch...

    IAR with the same firmware has a startup time of just 1.3ms and it does not grow when I add more code.

    Thank you!

    Best regards,

    Manuel

    StartUpMeasurementMSP430FR2311.zip

  • Manuel,

    Thank you for sending your project equivalent! After testing the start-up time with and without the switch statement I measured the delays to be 2.14ms and 1.921ms. My method was that I started a new project in CCS for MSP430FR2311 and then copied your main.c, spi.c, and spi.h files into the directory. Then I went into my project properties and optimized some settings to make the initialization code smaller (i.e. --cinit_hold_wdt to off,  --zero_init to off, and optimized compiler for speed). I programmed the device, disconnected it, and used a power supply to power up the board and measure the appropriate signals.

    I am not sure why you are seeing over 5ms of delay, but perhaps making a new project with the optimized settings could help you. Another thing for you to do is make sure all of your software and compiler versions are up to date (I am using compiler version TI v16.9.4.LTS).

    The difference you are seeing between CCS and IAR is merely due to the fact that they are based off of two completely difference compilers. Your best bet if you really want to dive into how the compilers differ is to post your inquiry in the TI C/C++ Compilers forum and reference this thread for background info.

    Best regards,

    Matt Calvo

  • Hi Matt,

    Thank you for making this test. Unfortunately, I'm not able to reproduce that. I made a new project for MSP430FR2311 and copied main.c, spi.c and spi.h in it and deleted the first two lines of main.c (includes).

    Then I went to project poperties and made the following things:

    - compiler version is TI v16.9.4.LTS
    - turned off --cinit_hold_wdt
    - turned off --zero_init
    - optimized compiler for speed

    Startup time is still 5ms. One of those options I mentioned above leads in a startup time which is 0.3ms less.

    Here is the new project I used (picture of my measurement is included in project root)

    Best regards,

    Manuel

    3324.Test.zip

  • Manuel,

    This most certainly sounds like it should be sent over to the compiler forum now because I have exhausted all avenues on the MSP430 and CCS side. Thank you for your patience and I hope you can figure out what is causing this delay. If you don't get a response on this thread after a couple of days then please make a new post directly on the TI C/C++ compiler forum so that their support team can see it.

    Best regards,

    Matt Calvo

**Attention** This is a public forum