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.

Can the RESET_VECTOR be redefined at compile time to a specific value?

Expert 1140 points

Hi,

My use case is the following: I have a bootloader (up to 4K in size, residing at 0x4400 to 0x5400) that has a main() function and application (starting from 0x4800) – they are organized as 2 separate projects (I want the bootloader to be flashed only once and not changed later).

I am using mspgcc.

Bootloader and application linker scripts are defined so that their .text sections (that go to “rom” memory region) are separated but they use the same “vector” memory region for .vector section (although the bootloader does not use any interrupts other than reset):

bootloader’s linker script excerpt:

MEMORY {
  …
  rom (rx)         : ORIGIN = 0x4400, LENGTH = 0x1000 /* END=0x5400, size 4K - bootloader code */
  rom_app (rx)     : ORIGIN = 0x5400, LENGTH = 0xab80 /* END=0xff80, size 43904 - the field-updatable application */
  vectors          : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000, size 128 as 64 2-byte segments */
  …
}

and the application’s linker script excerpt:

MEMORY {
  …
  rom (rx)         : ORIGIN = 0x5400, LENGTH = 0xab80 /* END=0xff80, size 43904 */
  vectors          : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000, size 128 as 64 2-byte segments */
  …
}

I need the bootloader’s main() function to be executed upon power up of the microcontroller. And this would be the case if I only flashed the bootloader’s .elf onto the flash (0xFFFE pointing to bootloader’s main() function).

But when I program the application’s image onto the flash the 0xFFFE will point to the application’s reset vector which is not a bootloader anymore.

Then of course the bootloader needs to jump to and execute the application’s entry point (0x5400) including the app's watchdog preparation, stack init etc. 

Is that doable? How can I define in the application’s code that the reset vector (0xFFFE) shall contain the bootloader’s init code (0x4400)?

Best Regards,
tml

  • Can you be a little more specific?

    You want the reset vector to point to the bootloader, but all the other vectors to point to the application?

  • Brian Boorman said:
    You want the reset vector to point to the bootloader, but all the other vectors to point to the application?

    That's right! The bootloader is not going to use any interrupts, it will just control the booting process, i.e. check if there is a new firmware to be copied from flash memory bank D to bank A and later just call the application (from bank A). The application will use the interrupts but the 0xFFFE cell shall have the bootloader's reset vector address, which in my example is 0x4400 so that after reset the bootloader starts first, not the application.

    As far as I can control internal reflashing done by bootloader (i.e skip when the target cell address is 0xFFFE), the problem is still valid when I load the .elf file via mspdebug - there I cannot control which addresses are written and which are not. That's why if I had the 0x4400 value in the application's vector for reset (0xFFFE) then the bootloader's vector table (with 0xFFFE set to 0x4400) could be overwritten with the same value.

  • tmi,

    I have been using a scheme very similar to yours. I did not encounter any difficulty and it works for me. I will describe the scheme in reverse order, as compared with your description, so that it is easier to understand. The only slight difference is in red.

    (1) To develop “Application” program, I modified the link command file so that the linker would not use a certain amount of the lower addressed Flash of the chip. For example, if the chip has Flash starting at 0x4400, I might tell the linker that Flash starts at 0x5400 instead of 0x4400 hence the linker will not try to use the first 4KB between 0x4400 and 0x5400. Nothing else is changed, I can now write and debug “Application” as usual. The only difference is, the chip appears to have less amount of Flash.

    As usual, the Linker can also generate MSP430.txt or Intel.hex file. My “Loader” described below can use those files without any change.

    (2) I developed a “Loader” program for the above “Application” program(s). During the development of this “Loader” program, I use the original linker command file. But I discipline myself as follows:

    a. The size of the “Loader” must fit into the 4KB (or whatever amount) of Flash reserved in (1) above.

    b. The “Loader” must not use any interrupt vector. Only the reset vector is used.

    c. When this “Loader” is told to erase Flash, it will not erase itself. Also, if it needs to erase the Flash sector that contains the reset vector, it will automatically re-write its own reset vector immediately after that sector is erased.

    d. When this “Loader” is told to write something at 0xFFFE-0xFFFF, it will not do that, but write that something at an known “Reserved” interrupt vector slot instead.

    e. When the “Loader” decides to start the “Application”, it will utilize that known “Reserved” interrupt vector to do so.

    -- OCY

  • TML,

    I would check the mspgcc documentation and see if there is a way to exclude the reset vector during compilation. IAR has this setting (right on the 1st tab of General Option in the Project Options).

    If you can do that, plus in your application hardcode the bootloader reset vector at address 0xFFFE then that should accomplish what you want.

    In IAR, you would do something like (Bootloader starts @ 0xF000):

    __root static unsigned int const BootloaderResetVector @ 0xFFFE = 0xF000;
    

**Attention** This is a public forum