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.

MSPBoot linker file issues.

Other Parts Discussed in Thread: MSP430F247

Hi Everyone,

I'm building a custom flash bootloader for an MSP430F247. I generated the linker files for the bootloader and the app using: MSPBootLinkerGen.pl 

The full command I executed for MSP430F247 is the based on its memory map and is as follows:

MSPBootLinkerGen.pl -file MCU_MSP430F247_bootloader -device MSP430F247 -params 0x8000 0xFFE0 0xFC00 60 16 0x1100 0x20FF 0x50 0x1000 0x10FF.

So there's a few things that I don't understand:

The linkerGen output for the app linker files looks something like this:

/* Flash memory addresses */
__Flash_Start = 0x8000; /* Start of Flash */
__Flash_End = 0xFFFF; /* End of Flash */
/* Reserved Flash locations for Bootloader Area */
__Boot_Start = 0xFC00; /* Boot flash */
__Boot_Reset = 0xFFFE; /* Boot reset vector */
__Boot_VectorTable = 0xFFE0; /* Boot vector table */
__Boot_SharedCallbacks_Len = 16; /* Length of shared callbacks (2 calls =4B(msp430) or 8B(msp430x) */
__Boot_SharedCallbacks = 0xFFD0; /* Start of Shared callbacks */
_BOOT_APPVECTOR = __Boot_SharedCallbacks; /* Definition for application table */


/* Reserved Flash locations for Application Area */
_AppChecksum = (__Flash_Start); /* CRC16 of Application */
_AppChecksum_8 = (__Flash_Start+2); /* CRC8 of Application */
_App_Start = (__Flash_Start+3); /* Application Area */
_App_End = (__Boot_Start-1); /* End of application area (before boot) */
_CRC_Size = (_App_End - _App_Start +1); /* Number of bytes calculated for CRC */
_App_Reset_Vector = (__Boot_Start-2); /* Address of Application reset vector */
_App_Proxy_Vector_Start = 0xFBC2; /* Proxy interrupt table */

.................

So App_Start seems to be (__Flash_Start+3) which will end up being 0x8003, if I'm not wrong.

The problem is after compiling the App the txt output looks something like this:

@0000
84 8E
@8004
0A 12 09 12 08 12 31 80 0E 00 0A 4E 08 4F 09 4C
C9 93 02 00 02 20 4C 43 55 3D 3D 90 0B 00 0E 2C
0D 5D 10 4D 2A 80 C2 82 CA 80 A0 80 90 82 76 80

.......

The issues are:

1) Program starts at address 0x8004. When bootloader checks for CRC if fails because it start calculation from 8003  as __App_Start indicates. Modifying the bootloader code is not a big deal of course, but why is this happening? Is it related to memory alignment? Can a program start in an odd address?

2) It adds some data in address 0x0000 which is not FLASH but Special register address. The consequences of this is that I can't flash the application because the debugger throws an error:

"MSP430: File Loader: Verification failed: Values at address 0x0000000000000000 do not match Please verify target memory and memory map."

I have no idea where this comes from because when I build the application with the default linker for this MCU there's nothing in address 0x0000.

Does someone know what could be going on here?

Thanks in advance.

  • By the way I'm using CCS Version: 6.1.1.00022 and my application is written in C++. I had to do some changed on the pragmas statement to make it compile. Is there any other changes I need to do on the linker file due to C++ language?

    Cheers,
  • Hi Matias,

    Do you think you could provide the entire linker file (maybe in a .zip file, I'm not sure if the forum will reject a .cmd file)? You can attach files to a post following the steps here: e2e.ti.com/.../148.4-5-attaching-a-file

    Seeing your whole linker file would help us to determine what may be going wrong here - we'd like to see some of the other definitions not shown in the snippet you provided.

    The 0x8004 address looks correct - that is the same behavior we expect and you see in the MSP-BOOT example projects. The 0x0000 though is of course wrong - looking at the data it is putting there it is 0x8E84. Can you open your .map file for the project and see what is at address 0x8E84 (this is the data @0000 84 8e as a word address)? I'm wondering if the project is not properly placing your reset/start vector and is putting it at 0x0000 instead.

    As a note, MSPBoot has not been tested with C++ so that is also another factor - there may be some custom project setting that is missing once you made this switch or something.

    Regards,
    Katie
  • Hi Katie,

    Thank you very much for your reply. Find attached the whole linker file.

    I looked at the map file and at address 0x8E84 we can find a rotuine called: __sti___6_main_c_28ff00f0.

    This are the references to the function in the map file:

    00008e84    0000013a     main.obj (.text:__sti___6_main_c_28ff00f0)

    00008e84  __sti___6_main_c_28ff00f0   

    This looks like it may be a problem.

    But still looking at the .TXT file the address on the reset vector (app_reset_vector) is set to: 0xB860 which appears to be the entry point in the  map file:

    ENTRY POINT SYMBOL: "_c_int00_noargs"  address: 0000b860. So I'm not sure it'a a reset vector problem.

    Hope we find the answer in this files.

    Thanks again!

    MCU_MSP430F247_bootloader_App.zip

  • Hi Katie.

    I actually found the problem and manage to fix it. Effectively address 0x8e84 was the main() address and the linker was writting it to 0x0000 because the linker file was missing a few sections:

    .pinit : {} > FLASH /* C++ Constructor tables */
    .init_array : {} > FLASH /* C++ Constructor tables */
    .mspabi.exidx : {} > FLASH /* C++ Constructor tables */
    .mspabi.extab : {} > FLASH /* C++ Constructor tables */

    I found out by comparing the default linker file with the ones provided in the mspboot examples.

    By adding this lines in the linker file the problem is fixed and program run fine. I guess the linker file templates being used are old or older versions.

    Thanks for your input which turned out really well.

    Cheers,
  • Hi Matias,

    I'm so glad to hear that you found your issue and thank you so much for sharing your solution here for others! I think we are working on a new revision of MSPBoot at some point in the near future so I'll make sure we check this for any app note update as well.

    Regards,
    Katie

**Attention** This is a public forum