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.

Startup code for msp430 in IAR

Other Parts Discussed in Thread: MSP430F5338

Hi all,

I am using IAR to develop my application using msp430f5338  uC. In that compiler reference manual the mentioned the startup code is available in the path of 430\src\lib but i am not able to see the path in the project. Do any one knows the path of start up code in IAR? Also the function __low_level_init is defined in my project main file but it is not called anywhere. If anyone tells how this function will be getting called during the compilation/runtime?

Thanks in advance

  • There is absolutely no need to mess around with those files as they're global to IAR settings and not just to your project
    if compiler see you are using int __low_level_init(void){

    it will run that just after it sets stackpointer but before it's running memcpy/memclr functions
    So a good place to stop WDT if you have a lot of data to set up.
    And also for example if you want to test why it reset and if it should keep ram data as is, change Return(1) value:
    1 - Perform data segment initialization.
    0 - Skip data segment initialization.
      


  • Hi,
    Thanks for your reply. Also I wanted to know who will put the initialized global and static variables to DATA segment and uninitialized global and static variables to .BSS segment? Is there any document available to understand the startup code functionalities?
  • Prakash Balagangatharan said:

     Also I wanted to know who will put the initialized global and static variables to DATA segment and uninitialized global and static variables to .BSS segment? Is there any document available to understand the startup code functionalities?

    The IAR tools use the convention that segments ending in _Z are cleared ("zeroed") by the startup code. The content of segments ending in _ID (located in read-only memory) are copied to the corresponding segment ending in _I (located in RAM). Uninitialized data is simply placed in segments ending in _N, which the startup code doesn't touch.

    All of this is described in the manual "IAR C/C++ Compiler User Guide for the Texas Instruments MSP430 Microcontroller Family", in the chapter "System startup and termination", accessible from the Help menu.

        -- Anders Lindgren, Author of the IAR compiler for MSP430

  • Hi

    Thanks for your reply. During the startup code the variables are loaded to the allocated segment, in this case whether the uninitialized variables are initialled to '0' and stored in .bss or it will be stored with some garbage values? If the variables are initialized as '0' the who will initialize this?
  • Prakash Balagangatharan said:
    During the startup code the variables are loaded to the allocated segment, in this case whether the uninitialized variables are initialled to '0' and stored in .bss or it will be stored with some garbage values? If the variables are initialized as '0' the who will initialize this?

    It depends on what you mean by "uninitialized". If you define a global variable using simply "int x;", the C language specifies that it should be cleared, so effectively this is the same as writing "int x = 0;". (Note: The same does not apply to auto variables.) In both cases, it is placed in the DATA16_Z or DATA20_Z segment and cleared by the startup code.

    However, if you use the IAR keyword "__no_init", as in "__no_init int x;" you will get a variable that isn't initialized at all by the startup code. In this case, it is placed in the DATA16_N or DATA20_N segment.

        -- Anders Lindgren

  • Thanks for your reply. What is the difference between debug mode and release mode of compilation. What exactly the compiler will does in these two modes?
  • Prakash Balagangatharan said:
    Thanks for your reply. What is the difference between debug mode and release mode of compilation. What exactly the compiler will does in these two modes?

    There are a number of small differences between the two settings:

    * Optimization levels. In Debug the default optimization setting is low, as higher optimization level may cause the code to be rewritten so much that it's hard to single-step it, the value of a variable may be displayed incorrectly etc.

    * In Release mode, the preprocessor symbol NDEBUG is defined, to disable assertions.

    * Terminal I/O. In debug mode, you can call functions like "printf" to print to the Terminal I/O window in Embedded Workbench. In Release mode, you will have to provide low-level function for reading and emitting bytes.

    * Debug information.

    Of course, the Debug and Release are just configuration names, where the default settings differ. You can change them as you like, create new configuration etc. (If you would like to see exactly the difference between two configurations you can compare the XML code of the corresponding sections in the .ewp file.)

        -- Anders

  • Hi Thanks for your reply. Recently I have went through the following page to know about what is interrupt stack.


    http://stackoverflow.com/questions/17768026/difference-between-isr-and-function-call

    Can you please explain is there any stack memory is available to handle interrupt alone in MSP430. If ,yes means how it will differ with the general stack(function stack)? 

    Thanks in advance.

  • Hi,

    Could anyone please answer about interrupt stack?
  • There is no separate stack for ISR.

    When a IRQ is trigged, hardware itself will put two 16bit values on the stack.
    The PC (program counter), that is the location "main" code was just about to execute.
    And the SR (Status register), that holds sleep-mode and c/z/n flags.

    C compiler will put more on the stack if it needs to use the registers for temporary vars.
    So it will insert push/pop code as needed, this is one reason your ISR should be light and lean as to much stack use slows down response.

    A exit of a ISR it will in hardware put SR and PC back to its regular values.
    A exit from sleep-mode can be done here by a "trick", modifying the LPM-bits in SR value that is on the stack, that hardware will then put back on exit.

**Attention** This is a public forum