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.

MSP430FR5994: FRBoot not compiling with 21.6.0 LTS compiler

Part Number: MSP430FR5994

Hello,

I have a customer developing an application based off of the MSP430FRboot 1.3 code, and their project was building using the 20.2.7 LTS compiler but once they upgraded to the new 21.6.0 LTS compiler the compilation failed on the file, TI_MSPBoot_MI_FRAMDualImg.c.

I compiled the example unmodified using the new compiler and my compiler segfaulted, and customer had to replace a couple pointers with the actual hex addresses in order for the build to succeed. The specific pointers/ addresses were &_Down_Offset_Size, &_Down_Offset1, &_Down_Offset2, BOOT_VECTOR_TABLE that needed to be replaced in the code.

Specific compiler invocation with the error below:

Invoking: MSP430 Compiler
"/Applications/ti/ccs1200/ccs/tools/compiler/ti-cgt-msp430_21.6.0.LTS/bin/cl430" -vmspx --code_model=large --data_model=large -O3 --opt_for_speed=0 --use_hw_mpy=F5 --include_path="/Applications/ti/ccs1200/ccs/ccs_base/msp430/include" --include_path="/Applications/ti/ccs1200/ccs/tools/compiler/ti-cgt-msp430_21.6.0.LTS/include" --include_path="/Users/munan/customer_apps/Kodak/MSPBoot_FR5994_UART" --include_path="/Users/munan/customer_apps/Kodak/MSPBoot_FR5994_UART/AppMgr" --include_path="/Users/munan/customer_apps/Kodak/MSPBoot_FR5994_UART/Comm" --include_path="/Users/munan/customer_apps/Kodak/MSPBoot_FR5994_UART/MI" --advice:power="all" --advice:power_severity=suppress --advice:hw_config=all --define=MSPBoot_20bit --define=MSPBoot_BSL --define=MSPBoot_CI_UART --define=__MSP430FR5994__ --define=_MPU_ENABLE -g --gcc --printf_support=minimal --diag_warning=225 --display_error_number --abi=eabi --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --preproc_with_compile --preproc_dependency="MI/TI_MSPBoot_MI_FRAMDualImg.d_raw" --obj_directory="MI"  "../MI/TI_MSPBoot_MI_FRAMDualImg.c"
MI/subdir_rules.mk:7: recipe for target 'MI/TI_MSPBoot_MI_FRAMDualImg.obj' failed
abnormal termination of /Applications/ti/ccs1200/ccs/tools/compiler/ti-cgt-msp430_21.6.0.LTS/bin/cg430
gmake: *** [MI/TI_MSPBoot_MI_FRAMDualImg.obj] Segmentation fault: 11
gmake: Target 'all' not remade because of errors.

I also checked on my side and reverting to the old compiler solves the issue. Is there something up with the 21.6.0 LTS compiler?

Munan

  • Hi Munan,

    Yes, you are right. It seems there are some error when using 21.6.0 LTS compiler. I am still under debugging of it and will feedback to you if any progress here

  • It seems there are some error when using 21.6.0 LTS compiler.

    This might for the same reason as the existing EXT_EP-10828 "MSP430 compiler segfaults with math operations on addresses of variables" which was reported against compiler MSP430_21.6.0.LTS

    The description of EXT_EP-10828 is:

    An expression like below which performs math operations on the addresses of
    variables will cause a segfault in the MSP430 code generator.
    uint32_v1 = (uint32_v1 - ((uint32_t) &uint16_v1)) + ((uint32_t) &uint16_v2);

    The MSP430FRboot 1.3 ../MI/TI_MSPBoot_MI_FRAMDualImg.c source file which Munan reported the compiler crash for, does appear to be using math operations on the addresses of variables.

    E.g. the TI_MSPBoot_MI_WriteByteDirect function has:

            // If address is an interrupt vector, copy directly to interrupt table
            addr = (addr - APP_VECTOR_TABLE) + BOOT_VECTOR_TABLE;

    Where TI_MSPBoot_MI.h has the defines:

    /*! Application Vector Table */
    #define APP_VECTOR_TABLE        ((uint32_t) &_Appl_Vector_Start)
    /*! Application Interrupt Table (from linker file) */
    #define BOOT_VECTOR_TABLE       ((uint32_t) &__Boot_VectorTable)

  • Hi Chester,

    Good catch! I am not aware about that.  So let wait  for the next version of the compiler TI v21.6.1.LTS to see if it fixed. 

  • I have tried this with 21.6.1.LTS compiler and the issue appears to be fixed.

**Attention** This is a public forum