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.

Custom Flash-Based Bootstrap Loader for MSP430F6736 (CCS 6.1.3, TI v15.12.1.LTS)

Other Parts Discussed in Thread: MSP430F6736, MSPBSL, MSP430F5438A

Hi everybody,

I try to create my own custom flash-based boot loader for a MSP430F6736 MCU.
Therefore I use the "MSPBSL_CustomBSL430 1_00_11_00" software package from TI.
I followed the documentation "SLAA450C (Creating a Custom Flash-Based Bootstrap Loader (BSL))"
and created a suitable "Linker command file".

The code compiles fine but the linker fails to place the BSL430_VERSION constants

The Linker command file looks like this:
MEMORY
{
...
ZAREA : origin = 0x1000, length = 0x0010
BSL430_VERSION_VENDOR : origin = 0x1010, length = 0x0001
BSL430_VERSION_CI : origin = 0x1011, length = 0x0001
BSL430_VERSION_API : origin = 0x1012, length = 0x0001
BSL430_VERSION_PI : origin = 0x1013, length = 0x0001
ZAREA_CODE : origin = 0x1014, length = 0x002E
FLASH : origin = 0x1042, length = 0x07AE
BSLSIG : origin = 0x17F0, length = 0x000C
JTAGLOCK_KEY : origin = 0x17FC, length = 0x0004
...
}
SECTIONS
{
...
.ZAREA : {} > ZAREA
.BSL430_VERSION_VENDOR : {} > BSL430_VERSION_VENDOR
.BSL430_VERSION_CI : {} > BSL430_VERSION_CI
.BSL430_VERSION_API : {} > BSL430_VERSION_API
.BSL430_VERSION_PI : {} > BSL430_VERSION_PI
.ZAREA_CODE : {} > ZAREA_CODE
.BSLSIG : {} > BSLSIG
.JTAGLOCK_KEY : {} > JTAGLOCK_KEY
...
}

and the linker error/warning messages are as follows:
section MSP430F6736_BBL3.out(.BSL430_VERSION_API) was padded by 1 to a MSP430F6736_BBL3 C/C++ Problem
section MSP430F6736_BBL3.out(.BSL430_VERSION_CI) at 01011h overlaps MSP430F6736_BBL3 C/C++ Problem
section MSP430F6736_BBL3.out(.BSL430_VERSION_PI) at 01013h overlaps MSP430F6736_BBL3 C/C++ Problem
section MSP430F6736_BBL3.out(.BSL430_VERSION_VENDOR) was padded by 1 MSP430F6736_BBL3 C/C++ Problem

Needless to say, that the flash area isn't properly initialized

tool chain: CCS 6.1.3, TI v15.12.1.LTS

What am I doing wrong?

Best Regards
Christoph

  • Hi Christoph,

    Are you able to build the MSP430F5438A_BSL example from the CustomBSL430 software package? I am not getting any similar errors with this example, the settings given, and compiler version TI v15.12.3.LTS. You might want to try updating your compiler version accordingly.

    Regards,
    Ryan
  • Hi Ryan,

    thank you very much for your reply. In the meantime I was able to build a boot loader, that is somehow working.

    What I'm puzzling about, is that if I build the CCS_v5.5.0_BSL-5438A boot loader from scratch (CCS 6.1.3, TI v15.12.3.LTS) as you advised, the result is obviously not working. 
    The created boot loader file(MSP430F5438A_BSL.txt) starts as follows:

    @1010
    00 08 08 04
    @1042
    81 00 00 5C B1 13 E0 01 0C 93 02 24 B0 13 8C 16
    0C 43 B0 13 64 10 B0 13 EA 17 32 D0 10 00 FD 3F

    Evidently, that .ZAREA and .ZAREA_CODE are missing. A few other things are also strange. An interrupt vector table is added and it seems that the resulting code doesn't fit into the 2k boot loader flash ...

    I reckon that I need to tweak the default settings of CCS to get a working result, but after re-reading SLAU319 and SLAA450 several times and browsing thru the TI wiki (<http://processors.wiki.ti.com/index.php/Custom_MSP430_BSL#Custom_MSP430_BSL_for_5xx_Devices>)  some problems still persist.

    Removing the interrupt table from the linker command file removes the interrupt table from the output file, with one exception.
    The TI linker always tries to place the reset vector (rts430x_sc_sd_eabi.lib : boot.obj (.reset)) in the boot loader output.
    Removing the Runtime support library results in unlinkable project. 

    How do I get rid of the reset vector? 

     

    Thank you very much in advance! Regards

    Christoph

  • Hi Cristoph,

    I'm glad to hear that you have a workaround while we evaluate this issue. I was able to replicate the binary image output and the results are unexpected. Clearly this project's native compiler (TI v4.1.9) and output format (legacy COFF) should be used, by doing so I was able to get the proper results. Have you evaluated the CUSTOM BSL project from the Wiki page? processors.wiki.ti.com/.../File:CUSTOM_BSL.zip

    Regards,
    Ryan
  • Hi Ryan,

    OK, I understand. I used the latest BSL code (MSP430BSL_1_00_12_00) from TI( <www.ti.com/.../mspbsl> )
    Where do I get the TI v4.1.9 compiler? I can't find it in the CCS App Center ...


    Best Regards
    Christoph
  • I should have provided instructions before as it isn't the easiest download to find, inside of CCS go to Help -> Install New Software -> Work with: Code Generation Tools Updates -> TI Compiler Updates.

    Regards,
    Ryan
  • Hello Ryan,

    thank you very much for your support! After re-installation of the TI v4.1.9 compiler, I was able to select it as the compiler version. I also downloaded and compiled the CUSTOM_BSL.zip source code from the TI wiki with the settings you mentioned.
    However, the 'problem', that the resulting boot loader contains a reset vector still exist. In my case BSL.txt still contains the following two lines
    @fffe
    CC 16

    As my boot loader checks the reset vector, to determine if an application is flashed, I actually need to clean up the boot loader file manually, which is annoying and error prone too. That is the main reason why I want to get rid of those two bytes ...


    Best regards
    Christoph
  • This is expected operation of the CUSTOM_BSL project as it is supposed to run the startup sequence described by the Wiki page and Section 1.2 of SLAA450, initialize the communication peripheral, and await further BSL instructions from a host. This is under the condition that it is the only program on the device, if an application has already been flashed (for example, the CUSTOM_BSL_APP project) then the reset vector will already have been re-written so that the application itself starts after a reset.

    Regards,
    Ryan
  • Hi Ryan,

    I think we have the same understanding on this topic.
    What I want to point out is, that the boot loader image, produced by CCS, writes data from address 0x1000 to 0x17FF, and 2 bytes of data to address 0xFFFE and 0xFFFF.
    As a consequence the reset vector isn't 'blank' anymore and the boot loader assumes that an application has already been flashed, but this isn't the case.
    The 'original' boot loader images for MSP430F673x_Family, supplied by TI (found in the '5xx_6xx_Released_BSL_Images' directory for example), contain only data from address 0x1000 to 0x17FF. I have to admit, that those files are created by IAR EW, but my assumption is that CCS and IAR are equal in this aspect. Isn't this the case?


    Best regards
    Christoph

  • Hi Christoph,

    Sorry for the confusion and thank you for your patience, I am on the same page now. This may be explained by the accompanying READ_ME.txt file: "In order to get the BSL to compile under CCS the following modifications were applied: * JMP instruction in CCS cannot point to non-local labels. This prevents the 0x1000 JMP instruction from pointing directly to _c_int00. Instead, a local jump to a branch was used. (see BSL430_Low_Level_Init.asm line 101)"

    So there could very well be a difference between CCS and IAR, I will attempt to loop in the author of this material to further clarify.

    Regards,
    Ryan
  • Hello Ryan,

    thank you very much for all your efforts! I will stay tuned.

    Kind regards,
    Christoph

  • Feedback from the author is as below:

    "This reset vector at 0xFFFE is also created by IAR project. Just they are manually removed after building the images. The boot code is taking care to start the BSL so the reset vector at 0xFFFE is not needed. In BSL430_Low_Level_Init.asm in line 242 the BslEntryLoc is set to the BSL_Entry_JMP at the beginning of the Z-Area. This contains a jump to C_Branch with branches to the #_c_init00 and the BSL starts."

    Regards,
    Ryan
  • Hello Ryan,

    thank you very much for the feedback. As a solution for my issue I wrote a little tool which deletes the reset vector at address 0xfffe automatically.

    Best regards
    Christoph

**Attention** This is a public forum