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.

Start Code Another Address

Other Parts Discussed in Thread: MSP430F6779

Hi, 

I have msp430f6779 mcu and it starts 0xc000 address after a reset so is written 0xC000 in 0xFFFE(Reset Vector Address) address.

Here is my question I want to change that 0xC000 value which resides in 0xFFFE address. How can I do that ? Can you explain me deeply ?

Berst regards..

  • How you do it depends on the tools you are using. I can help you out if you are using the IAR tools...

        -- Anders Lindgren, IAR Systems

  • I use IAR yes. And I solved my problem writing a startup code. But I need more information about IAR startup code in assembly. Do you have any document about that ?

    My solution is :

    // ---------------------------------------------------------
    // Define reset vector.
    //

    MODULE ?reset_vector

    RSEG RESET:CONST:NOROOT(1)
    PUBLIC ?reset_vector
    EXTERN __program_start

    ?reset_vector:
    DC16 0x1800//__program_start

    ENDMOD

    Best Regards

  • Baycan,

    In IAR, you would modify your linker script .xcl file to place CSTART section in a different address region.

    Example:

    -Z(CODE) CSTART=D000-DFFF

    would place the CLIB startup code that executes at reset (before calling main() ) at address 0xD000. Where the reset of your code resides would depend on the other linker directives. You can read the XLINK User's Guide for more information.

  • baycan vural said:

    I use IAR yes. And I solved my problem writing a startup code. But I need more information about IAR startup code in assembly. Do you have any document about that ?

    There is no documentation of the cstartup file itself, except for the comments in the file (which are pretty extensive). The compiler manual, however, contains information on all the segments that are used in the file. I can describe a bit how it is organized.

    Normally, IAR Embedded Workbench adds the command like option "-s __program_start" when linking. This includes the start up code, which in turn includes the ?reset_vector segment, which populates the reset vector.

    Depending on how your application is organized, you can make sure that the reset vector is different from the default. The first question, however, is if you application use the startup code at all?

    One method has already been suggested, simply place the startup code at a different location. You found another, replace the module ?reset_vector with a custom one.

    Yet another way is to select "Options->Linker->Config->Override default program entry". There you can either select another label to be used as the start label, alternatively select "Defined by application". (Technically, the former emits "-s" and the specified symbol and the latter suppress the option altogether.) Either way, the reset vector is not populated by the runtime library. This way, you can simply define your own. This can be done using assembler or by defining an interrupt function in C using the reset vector. (A small warning: the vector number is calculated from the beginning of the interrupt vector table. As the size of the table differs between devices, the value of the reset vector do to. Using the predefined symbol RESET_VECTOR should always work correctly, though.)

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

  • Is there a reason for asking this?
    In assembly, the reset vector will point to where you make it point to. I wouldn’t use a numerical constant, but rather a symbol (e.g. the label of your code start). If you for some reason move your code, a fixed numerical constant would cause the MSP to jump into the void, if you forget to change it.
    In C, the linker will place your code into the flash and then make the reset vector point to where the startup code ended up. And usually you don’t have to care for it at all.
    The invention of a linker has made life so much easier. You must have a really good reason to go back to manual adjustments.

    Anders has given some good advice for IAR (and who if not him could give it), but personally, I suggest not tampering with all this at all, if not absolutely necessary, as it is not portable across compilers and may even break on new versions of the same compiler.

  • Hi,

    First of all I want to say thank you for all of your answers. And Jens, I think I have good reason to change my reset address with numerical constant. Maybe I have been doing some mistakes about that but please let me know.

    I am writing a jump code in INFO D area. And I want to make it my code starts from at this area.This is not a startup code actually.

    Why I need this jump code ? It is simple. I have 2 different code in my flash memory.One of Bootloader and one of Application code. Bootloader resides in flash bank 1 which start 02C000h. As you know bootloader should work every reset as you can see this address can not store in vector table. So I need an 16 bit address for Reset address.(I can not use bank 0 for bootloader. It is includes application code inside).

    Best Regards.

       

  • Now it becomes clearer. You want to point the reset vector to an address that is not part of the currently compiled project. Yes, then you’ll need to do it this way. However, it is tricky still.

    A possible workaround would be to put some code into the standard startup code that jumps to your bootloader. (like writing your own pre_init function that doesn’t return but rather jumps to the bootloader).

    Another, completely different would be the way that has been discussed a lot: using a proxy vector table and put the bootloader at the end of lower 64k. Then the application is compiled with its vector table moved to below the boot loader, with the area of the boo loader and the real vector table spared form the available regions in the project.

    e.g.: Bootloader located 0xE000-0xF000, including vector table with all entries pointing to a jumptable in this area that jumps indirectly, using a table on 0xDF00 (where the application has its vector table)

  • Jens thanks for your opinions. It is really helpfull to discuss these things who someone can understand you.

     And yes I read many things about like you said:

    Another, completely different would be the way that has been discussed a lot: using a proxy vector table and put the bootloader at the end of lower 64k. Then the application is compiled with its vector table moved to below the boot loader, with the area of the boo loader and the real vector table spared form the available regions in the project.


    But I want to separate bootloader application and real application with different flash banks. because it is really easy and fast way to deleting all registers of a single bank. When I need a firmware upgrade, I just delete all bank(e.g all  registers of bank 1). And then I can write again. So I choosed this tricky still :)

    But anyway I really appreciated to your opinions.

    Best Regards..

  • It is indeed a tradeoff - more project managing effort (and slower erase operation) on one side (BSL in main memory) and much higher development effort and risk of bricking the device during BSL development on the other (BSL in BSL area)

    When trying to replace the BSL with your own, be sure to use a target board with a ZIF socket, so you can easily replace the MSP if you should brick it during the development.

    BTW: when using a proxy vector table, you can have the whole application in upper memory. There is no need to have the ISRs in the lower 64k as long as the jump table of the BSL is there. So you can have the BSL in bank 0 and the application in bank 1 and download the new applicaiton into bank 2 (if there). Makes the generation of the vectors a bit more complicated, as you now need a 32bit vector table. But this is not really problem.

**Attention** This is a public forum