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.

Changes in the reset vector

Other Parts Discussed in Thread: MSP430F4616

Hi all,

I am working with msp430f4616 and I would like to know what are the factors that affects the reset vector. Due to some program restrictions I would like it to be fixed, but it is changing after modifying the code.

I am using IAR 341 compiler.

 

 Thank you in advance and best regards,

       Carmen.

  • The reset vector points to a particular label which the IAR Embedded Workbench toolchain uses for the initialization of the C environment.  I don't recall exactly what that label is, but unless you use the facilities of the IAR tools to fix this location in memory, it may get moved around from compile to compile.

    The IAR documentation should have some constructs described to force the location of this routine to a particular memory location.

  • Hi Carmen, why do you want the reset vector to be fixed?

    Without seeing your code I would guess the issue is that the reset vector is set to point at the location of the "main" function but when you change the code the placement of this function moves when it is recompiled.  By playing about with the linker file you could locate a segment at a specific address and make sure your main function goes in there (exclusively) but this is not ideal...

  • Hi Carmen,

    please read post:
    http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/p/102456/361082.aspx#361082

    There is information where you can find reset vector definition for IAR, and how to modify it when you need to install a hook.
    I think it may solve your problem.

    According to your question, reset vector, i.e. address called after reset must be in first part of the flash (0-64KB) because vector itself is 16 bits.
    I saw that IAR usually tries to put at the begining of the flash, but it may be not always true.

    Regards,
    Piotr Romaniuk, Ph.D.
    ELESOFTROM

     

**Attention** This is a public forum