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.

abnormal termination of "~ti-cgt-msp430_16.3.0.STS/bin/asm430"

Other Parts Discussed in Thread: CCSTUDIO, MSPWARE, MSP430WARE, MSP430FR4133

Greetings all;

I believe I have a bad compiler on my hands. I have run the compiler command both from the IDE and from a terminal.

I continuously get this error "Illegal instruction", it does not matter if I'm compiling a program or querying for help from

the binary.

I built an empty project with just a "main" function and it just will not compile. Vary frustrating, as this kind of error indicates

that there is something wrong with the "asm430" binary, an internal error. TI may need to recompile, re-release this tool.

Or does any one have any thoughts on this or a solution they can recommend?

Thanks in advance JBG.

  • James Grieger said:
    I continuously get this error "Illegal instruction", it does not matter if I'm compiling a program or querying for help from the binary.

    Can you confirm which operating system and CPU are on the PC in which you are getting the "illegal instruction"?

    My guess is that you are using Linux.

    On a CentOS 6.7 64-bit system with i5-2310 CPU I am unable to repeat the "Illegal instruction" error, in that querying the help from the ti-cgt-msp430_16.3.0.STS/bin/asm430 or compiling a program is successful.

    Not sure if you are suffering the "illegal instruction" error due asm430 attempting to execute an opcode which is not available on your CPU, or if you have discovered a bug in the asm430 program.

  • Chester yes I'm using Linux: This is what I've got;

    System Information:
    Command:     * Output:
    uname -s        Linux
    uname -r        3.16.7-35-default
    uname -v        #1 SMP Sun Feb 7 17:32:21 UTC 2016 (832c776)
    uname -m      i686
    uname -p       athlon
    uname -i        i386
    uname -o      GNU/Linux

    This is a 32 bit machine. It works so I use it. Don't need much compute power for a cross compiler. I would use a 16 bit machine for this if the software was available.

    The following is a brief list of whats installed on this system:

    Code Composer Studio Information:
    Version:  6.1.2.00015

    Installed Software:
    As viewed from the installation summery page.
    Name:
    Version:
    Ld:
    Provider:

    C/C++ GCC Cross Compiler Support
    8.5.0.201409172108
    org.eclipse.cdt.build.crossgcc.feature.group
    Eclipse CDT

    Code Composer Studio IDE MSP430 Components
    6.1.1.201512011200
    com.ti.ccstudio.msp430.feature.group
    Texas Instruments

    MSP430 Compiler Tools
    16.3.0
    com.ti.cgt.msp430.16.linux.feature.group
    Texas Instruments

    MSP430 Compiler Tools
    4.4.5
    com.ti.cgt.msp430.4.4.linux.feature.group
    Texas Instruments

    MSP430 GCC Tools (Linux)
    5.3.0.105
    com.ti.gcc.msp430.linux.feature.group
    Texas Instruments

    MSPWare for Linux
    3.30.0.18
    com.ti.msp430.msp430ware.linux.feature.group
    Texas Instruments

    Any suggestions greatly appreciated.
     Thanks.

  • James Grieger said:
    This is a 32 bit machine. It works so I use it. Don't need much compute power for a cross compiler. I would use a 16 bit machine for this if the software was available.

    I used the opcode.sh script referenced from How to check if a binary requires SSE4 or AVX on Linux to attempt to determine which instruction set the ti-cgt-msp430_16.3.0.STS/bin/asm430 program requires. This shows that MMX, SSE and SSE2 instructions are in the program.

    Can you post the output of /proc/cpuinfo to show which instruction set is supported on your PC?

  • Ok this is "/proc/cpuinfo"

    processor    : 0
    vendor_id    : AuthenticAMD
    cpu family    : 6
    model          : 10
    model name    : AMD Athlon(tm) XP 3000+
    stepping       : 0
    cpu MHz        : 2058.962
    cache size    : 512 KB
    physical id    : 0
    siblings         : 1
    core id           : 0
    cpu cores     : 1
    apicid            : 0
    initial apicid    : 0
    fdiv_bug       : no
    f00f_bug      : no
    coma_bug    : no
    fpu                  : yes
    fpu_exception    : yes
    cpuid level        : 1
    wp                : yes
    flags               : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
    bogomips        : 4117.92
    clflush size       : 32
    cache_alignment    : 32
    address sizes    : 34 bits physical, 32 bits virtual
    power management: ts

    I've tried the script you suggested. It returns the error "/bin/bash^M: bad interpreter: No such file or directory".
     So I will look into this script to see if I can get it to run.

    Thanks J.B.G.

  • James Grieger said:
    flags               : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow

    The flags for your CPU shows no support for sse2 instructions, and the the opcode.sh script appeared to show that there are some sse2 instructions in the asm430 program. Maybe running the asm430 program under gdb will show the instruction which causes the "illegal instruction" error to determine if the cause is an sse2 instruction.

    James Grieger said:
    I've tried the script you suggested. It returns the error "/bin/bash^M: bad interpreter: No such file or directory".
     So I will look into this script to see if I can get it to run.

    I got the same error when I first downloaded the script. The problem was that the web browser saved the script with Windows line endings (CR LF). To get the script to run had to change to Linux line endings (LF).


  • Chester Gillon said:

    The flags for your CPU shows no support for sse2 instructions, and the the opcode.sh script appeared to show that there are some sse2 instructions in the asm430 program. Maybe running the asm430 program under gdb will show the instruction which causes the "illegal instruction" error to determine if the cause is an sse2 instruction.

    I got the same error when I first downloaded the script. The problem was that the web browser saved the script with Windows line endings (CR LF). To get the script to run had to change to Linux line endings (LF).


    Agreed, I did a copy/paste to another file with CR/LF translation turn on. The script ran just fine however when I ran it on the asm430 binary it wanted to display the entire disassembled file. So I'm now going to check into the Intel SDE to see if I can get the binary to run inside this shell. If the utility can emulate the required instructions then that should be the fix. I'll post back the results of the test, either good or bad.

    Thanks J.B.G.

  • We are unable to reproduce this problem.  Do you see the same thing when you use earlier revisions of the compiler?  I'd appreciate if you would try version 15.12.x.LTS.  See this wiki article for the details on how to download the compiler.  Do you have access to other computers with the same configuration?  Do they have the same problem?

    Thanks and regards,

    -George

  • George Mock said:
    We are unable to reproduce this problem.

    From running strings on ti-cgt-msp430_16.3.0.STS/bin/asm430 and ti-cgt-msp430_15.12.1.LTS/bin/asm430 they appear to have been compiled using GCC 4.1.1 on an Ubuntu 4.8.2-19ubuntu1 system.

    Do you know which compiler options are used to build the TI code generation tools for Linux?

    The interesting GCC flags are the -march and -mtune which determine the type of intel CPU and thus generated instructions.

  • Using the -v flag shows that GCC 4.1.1 was configured for i686-pc-linux-gnu
    The only relevant -m flag used was -m32
  • James Grieger said:
    Agreed, I did a copy/paste to another file with CR/LF translation turn on. The script ran just fine however when I ran it on the asm430 binary it wanted to display the entire disassembled file.

    The opcode.sh script was my initial attempt to determine which instructions were in the asm430 program, the script just statically lists instructions of a specified type without knowing if the instructions are executed.

    James Grieger said:
    So I'm now going to check into the Intel SDE to see if I can get the binary to run inside this shell

    By running the asm430 program under the Intel SDE with the -mix option can get a static list of all the instructions in the executable, and a dynamic list of the instructions which were actually executed. On closer investigation believe that the asm430 program created by GCC 4.1.1 compiler is using the cpuid instruction to determine which instructions are supported on the CPU, and then dynamically changing its behavior. Disassembling the asm430 program shows run-time library functions such as memset calling __init_cpu_features, where __init_cpu_features uses the cpuid instruction.

    Agree that the simplest work-around for you to try is to run the compiler in the Intel SDE.

    I have in the past seen X86 "illegal instructions" generated on a specific type of CPU because some library code didn't correctly detect the type of CPU, and then attempted to execute an instruction which wasn't supported by the CPU. To investigate that you would have to trap which instruction generates the "illegal instruction" in the asm430 program. e.g. with a core dump or running asm430 under GDB.

  • Greetings all;

    I've tried the SDE wrapper and it stated that it needs SSE2 support from the processor? So that idea is out. Maybe it doesn’t like the AMD processor.

    I got this when I debugged asm430:

    gdb on program "asm430"
    (gdb) file asm430
    Reading symbols from asm430...(no debugging symbols found)...done.
    (gdb) r
    Starting program: /opt/ti/ccsv6/tools/compiler/ti-cgt-msp430_16.3.0.STS/bin/asm430 asm430
    Got object file from memory but can't read symbols: File truncated.

    Program received signal SIGILL, Illegal instruction.
    0x0821df67 in sin ()
    (gdb) q
    A debugging session is active.

            Inferior 1 [process 1832] will be killed.

    Quit anyway? (y or n) y

    I did a search for the "opcode.sh" script (in the base directory -- "/opt/ti") and did not find it. I did find the "install_drivers.sh" script, but I have already run this script at the time of install. Im now going to look for one of the older compilers and see if that becomes a fix, as there are a lot of Linux and Processor flavors; one size does not fit all. It would be nice if TI could release the source to the asm430 compiler, that would fix this problem. But I suspect that is not an option. I will check into the older versions of the tools to see what I can find, I will post back the results.

    Thanks J.B.G.

  • Thanks George

    I downgraded to compiler version 4.3.8 but then I get other issues:

    **** Build of configuration Debug for project OutOfBox_MSP430FR4133 ****

    /opt/ti/ccsv6/utils/bin/gmake all

    Building file: ../StopWatchMode-new.c

    Invoking: MSP430 Compiler

    "/opt/ti/ccsv6/tools/compiler/msp430_4.3.8/bin/cl430" -vmspx --abi=eabi --include_path="/opt/ti/ccsv6/ccs_base/msp430/include" --include_path="/root/workspace_v6_1/OutOfBox_MSP430FR4133/driverlib/MSP430FR2xx_4xx" --include_path="/opt/ti/ccsv6/tools/compiler/msp430_4.3.8/include" --advice:hw_config=all -g --define=__MSP430FR4133__ --diag_warning=225 --display_error_number --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --printf_support=minimal --preproc_with_compile --preproc_dependency="StopWatchMode-new.pp" "../StopWatchMode-new.c"

    Finished building: ../StopWatchMode-new.c

    Building file: ../StopWatchMode.c

    Building file: ../TempSensorMode.c

    Building file: ../hal_LCD.c

    Building file: ../main.c

    Building file: ../driverlib/MSP430FR2xx_4xx/adc.c

    Building file: ../driverlib/MSP430FR2xx_4xx/crc.c

    Building file: ../driverlib/MSP430FR2xx_4xx/cs.c

    Building file: ../driverlib/MSP430FR2xx_4xx/eusci_a_spi.c

    Building file: ../driverlib/MSP430FR2xx_4xx/eusci_a_uart.c

    Building file: ../driverlib/MSP430FR2xx_4xx/eusci_b_i2c.c

    Building file: ../driverlib/MSP430FR2xx_4xx/eusci_b_spi.c

    Building file: ../driverlib/MSP430FR2xx_4xx/framctl.c

    Building file: ../driverlib/MSP430FR2xx_4xx/gpio.c

    Building file: ../driverlib/MSP430FR2xx_4xx/lcd_e.c

    Building file: ../driverlib/MSP430FR2xx_4xx/pmm.c

    Building file: ../driverlib/MSP430FR2xx_4xx/rtc.c

    Building file: ../driverlib/MSP430FR2xx_4xx/sfr.c

    Building file: ../driverlib/MSP430FR2xx_4xx/sysctl.c

    Building file: ../driverlib/MSP430FR2xx_4xx/timer_a.c

    Building file: ../driverlib/MSP430FR2xx_4xx/tlv.c

    Building file: ../driverlib/MSP430FR2xx_4xx/wdt_a.c

    Building target: OutOfBox_MSP430FR4133.out

    Invoking: MSP430 Linker

    "/opt/ti/ccsv6/tools/compiler/msp430_4.3.8/bin/cl430" -vmspx --abi=eabi --advice:hw_config=all -g --define=__MSP430FR4133__ --diag_warning=225 --display_error_number --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --printf_support=minimal -z -m"OutOfBox_MSP430FR4133.map" --heap_size=160 --stack_size=160 --cinit_hold_wdt=on -i"/opt/ti/ccsv6/ccs_base/msp430/include" -i"/opt/ti/ccsv6/tools/compiler/msp430_4.3.8/lib" -i"/opt/ti/ccsv6/tools/compiler/msp430_4.3.8/include" --reread_libs --warn_sections --display_error_number --xml_link_info="OutOfBox_MSP430FR4133_linkInfo.xml" --rom_model -o "OutOfBox_MSP430FR4133.out" "./StopWatchMode-new.obj" "./StopWatchMode.obj" "./TempSensorMode.obj" "./hal_LCD.obj" "./main.obj" "./driverlib/MSP430FR2xx_4xx/adc.obj" "./driverlib/MSP430FR2xx_4xx/crc.obj" "./driverlib/MSP430FR2xx_4xx/cs.obj" "./driverlib/MSP430FR2xx_4xx/eusci_a_spi.obj" "./driverlib/MSP430FR2xx_4xx/eusci_a_uart.obj" "./driverlib/MSP430FR2xx_4xx/eusci_b_i2c.obj" "./driverlib/MSP430FR2xx_4xx/eusci_b_spi.obj" "./driverlib/MSP430FR2xx_4xx/framctl.obj" "./driverlib/MSP430FR2xx_4xx/gpio.obj" "./driverlib/MSP430FR2xx_4xx/lcd_e.obj" "./driverlib/MSP430FR2xx_4xx/pmm.obj" "./driverlib/MSP430FR2xx_4xx/rtc.obj" "./driverlib/MSP430FR2xx_4xx/sfr.obj" "./driverlib/MSP430FR2xx_4xx/sysctl.obj" "./driverlib/MSP430FR2xx_4xx/timer_a.obj" "./driverlib/MSP430FR2xx_4xx/tlv.obj" "./driverlib/MSP430FR2xx_4xx/wdt_a.obj" -l"libc.a"

    <Linking>

    warning #10420-D: For FRAM devices, at start up, the GPO power-on default

    high-impedance mode needs to be disabled to activate previously configured

    port settings. This can be done by clearing the LOCKLPM5 bit in PM5CTL0

    register.

    error #10056: symbol "stopWatchModeInit" redefined: first defined in

    "./StopWatchMode-new.obj"; redefined in "./StopWatchMode.obj"

    error #10056: symbol "Hours" redefined: first defined in

    "./StopWatchMode-new.obj"; redefined in "./StopWatchMode.obj"

    error #10056: symbol "resetStopWatch" redefined: first defined in

    "./StopWatchMode-new.obj"; redefined in "./StopWatchMode.obj"

    error #10056: symbol "Seconds" redefined: first defined in

    "./StopWatchMode-new.obj"; redefined in "./StopWatchMode.obj"

    error #10056: symbol "Inc_RTC" redefined: first defined in

    "./StopWatchMode-new.obj"; redefined in "./StopWatchMode.obj"

    error #10056: symbol "Centiseconds" redefined: first defined in

    "./StopWatchMode-new.obj"; redefined in "./StopWatchMode.obj"

    error #10056: symbol "stopWatch" redefined: first defined in

    "./StopWatchMode-new.obj"; redefined in "./StopWatchMode.obj"

    error #10056: symbol "displayTime" redefined: first defined in

    "./StopWatchMode-new.obj"; redefined in "./StopWatchMode.obj"

    error #10056: symbol "Minutes" redefined: first defined in

    "./StopWatchMode-new.obj"; redefined in "./StopWatchMode.obj"

    error #10056: symbol "count" redefined: first defined in

    "./StopWatchMode-new.obj"; redefined in "./StopWatchMode.obj"

    warning #10247-D: creating output section ".stack" without a SECTIONS

    specification

    warning #10229-D: output section ".data" refers to load symbol "BAKMEM2_L" and

    hence cannot be compressed; compression "rle" is ignored

    undefined first referenced

    symbol in file

    --------- ----------------

    ADCMEM0 ./TempSensorMode.obj

    BAKMEM0_H ./StopWatchMode-new.obj

    BAKMEM0_L ./StopWatchMode-new.obj

    BAKMEM1_H ./StopWatchMode-new.obj

    BAKMEM1_L ./StopWatchMode-new.obj

    BAKMEM2_H ./main.obj

    BAKMEM2_L ./main.obj

    BAKMEM3_H ./main.obj

    BAKMEM3_L ./main.obj

    BAKMEM4_H ./TempSensorMode.obj

    BAKMEM4_L ./main.obj

    BAKMEM5 ./TempSensorMode.obj

    BAKMEM6 ./TempSensorMode.obj

    BAKMEM7_H ./StopWatchMode-new.obj

    LCDBM0W_L ./StopWatchMode-new.obj

    LCDM0W_L ./StopWatchMode-new.obj

    LCDMEMCTL ./StopWatchMode-new.obj

    PAOUT_L ./TempSensorMode.obj

    SYSRSTIV ./main.obj

    TA0CTL ./StopWatchMode-new.obj

    WDTCTL /opt/ti/ccsv6/tools/compiler/msp430_4.3.8/lib/rts430x_lc_sd_eabi.lib<autoinit.obj>

    error #10234-D: unresolved symbols remain

    >> Compilation failure

    error #10010: errors encountered during linking; "OutOfBox_MSP430FR4133.out"

    not built

    gmake: *** [OutOfBox_MSP430FR4133.out] Error 1

    **** Build Finished ****

    I donot know how to kill the redefinition warning flag, not that familiar with the IDE/Compiler

    yet.

    I believe that the newer compiler was built on a host that is a little more up to date then the machine

    I'm using, plus I'm using an AMD processor.

    Thanks J.B.G.

  • I can explain many of the errors emitted by the linker.  I cannot tell you the best way to fix them.  For errors that are repeated many times, I only explain the first one.

    James Grieger said:

    error #10056: symbol "stopWatchModeInit" redefined: first defined in

    "./StopWatchMode-new.obj"; redefined in "./StopWatchMode.obj"

    This says the symbol stopWatchModeInit (probably a function) is defined (has a full implementation) in two source files: StopWatchMode-new.c and StopWatchMode.c.  One of them must be removed.  One wild guess ... A build configuration parameter is missing or wrong.

    James Grieger said:

    warning #10247-D: creating output section ".stack" without a SECTIONS

    specification

    This means you should be concerned about two problems.  One, you are not setting the size of the stack with the option --stack=size .  Two, the .stack section is allocated to memory according the default settings of the linker, which is probably wrong.

    James Grieger said:

    warning #10229-D: output section ".data" refers to load symbol "BAKMEM2_L" and

    hence cannot be compressed; compression "rle" is ignored

    I recommend you ignore this one for now.  Everything will still work.  But it takes up a bit more memory than is possible.

    James Grieger said:

    undefined first referenced

    symbol in file

    --------- ----------------

    ADCMEM0 ./TempSensorMode.obj

    That says the file TempSensorMode.c uses the symbol ADCMEM0 (probably data), but there is no definition of that symbol.  You have to supply the code which defines this symbol.  Perhaps those symbols are defined in libraries that you forgot to use in the link.

    Thanks and regards,

    -George

  • James Grieger said:
    I downgraded to compiler version 4.3.8 but then I get other issues:

    It looks like you are compiling a modified version of the OutOfBox_MSP430FR4133 example from MSPWare.

    Under Linux (CentOS 6.7) with an AMD A6-1450 CPU I was able to get the unmodified OutOfBox_MSP430FR4133 MSPWare example to compile and link successfully using both TI compiler versions 16.3.0 and 4.3.8.

    I think there are two reasons for your linker errors:

    1) A copy of the original source file StopWatchMode.c was made, with the copy named StopWatchMode-new.c. Having both copies of the source file in the project causes the linker errors about duplcate symbols such as:

    James Grieger said:
    error #10056: symbol "stopWatchModeInit" redefined: first defined in

    "./StopWatchMode-new.obj"; redefined in "./StopWatchMode.obj"

    Either delete one copy from the project, or exclude one copy from the build. To exclude from the build right-click on the sorce file in the CCS Project Explorer and select "Exclude from Build".

    2) The linker command file, which defines the sections and peripheral addresses, has either been deleted from the project or excluded from the build.

    The missing linker command files leads to errors about unresolved symbols for peripherals such as:

    James Grieger said:
    undefined first referenced

    symbol in file

    --------- ----------------

    ADCMEM0 ./TempSensorMode.obj

    And the warning about creating an output section with a SECTIONS specification:

    James Grieger said:
    warning #10247-D: creating output section ".stack" without a SECTIONS

    specification

    Where you able to compile and link an unmodified OutOfBox_MSP430FR4133 example from MSPWare using the v4.3.8 compiler?

    For reference, this is the linker command line from a succesfull link of the OutOfBox_MSP430FR4133 example, which contains a reference to the "../lnk_msp430fr4133.cmd" linker command file:

    Invoking: MSP430 Linker
    "/opt/ti/ti_ccs6_1/ccsv6/tools/compiler/msp430_4.3.8/bin/cl430" -vmspx --abi=eabi --advice:power="all" --advice:hw_config=all -g --define=__MSP430FR4133__ --diag_warning=225 --display_error_number --diag_wrap=off --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --printf_support=minimal -z -m"OutOfBox_MSP430FR4133.map" --heap_size=160 --stack_size=160 --cinit_hold_wdt=on -i"/opt/ti/ti_ccs6_1/ccsv6/ccs_base/msp430/include" -i"/opt/ti/ti_ccs6_1/ccsv6/tools/compiler/msp430_4.3.8/lib" -i"/opt/ti/ti_ccs6_1/ccsv6/tools/compiler/msp430_4.3.8/include" --reread_libs --warn_sections --display_error_number --diag_wrap=off --xml_link_info="OutOfBox_MSP430FR4133_linkInfo.xml" --rom_model -o "OutOfBox_MSP430FR4133.out" "./StopWatchMode.obj" "./TempSensorMode.obj" "./hal_LCD.obj" "./main.obj" "./driverlib/MSP430FR2xx_4xx/adc.obj" "./driverlib/MSP430FR2xx_4xx/crc.obj" "./driverlib/MSP430FR2xx_4xx/cs.obj" "./driverlib/MSP430FR2xx_4xx/eusci_a_spi.obj" "./driverlib/MSP430FR2xx_4xx/eusci_a_uart.obj" "./driverlib/MSP430FR2xx_4xx/eusci_b_i2c.obj" "./driverlib/MSP430FR2xx_4xx/eusci_b_spi.obj" "./driverlib/MSP430FR2xx_4xx/framctl.obj" "./driverlib/MSP430FR2xx_4xx/gpio.obj" "./driverlib/MSP430FR2xx_4xx/lcd_e.obj" "./driverlib/MSP430FR2xx_4xx/pmm.obj" "./driverlib/MSP430FR2xx_4xx/rtc.obj" "./driverlib/MSP430FR2xx_4xx/sfr.obj" "./driverlib/MSP430FR2xx_4xx/sysctl.obj" "./driverlib/MSP430FR2xx_4xx/timer_a.obj" "./driverlib/MSP430FR2xx_4xx/tlv.obj" "./driverlib/MSP430FR2xx_4xx/wdt_a.obj" "../lnk_msp430fr4133.cmd"  -l"libc.a" 
    <Linking>
    warning #10420-D: For FRAM devices, at start up, the GPO power-on default high-impedance mode needs to be disabled to activate previously configured port settings. This can be done by clearing the LOCKLPM5 bit in PM5CTL0 register.
    warning #10229-D: output section ".data" refers to load symbol "_nop" and hence cannot be compressed; compression "rle" is ignored
    remark #10372-D: (ULP 4.1) Detected uninitialized Port A in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.
    remark #10372-D: (ULP 4.1) Detected uninitialized Port B in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.
    remark #10372-D: (ULP 4.1) Detected uninitialized Port C in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.
    remark #10372-D: (ULP 4.1) Detected uninitialized Port D in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.
    Finished building target: OutOfBox_MSP430FR4133.out
    

  • +------------------------------------------------------------------------------+
    I can explain many of the errors emitted by the linker.  I cannot tell you 
    the best way to fix them.
    For errors that are repeated many times, I only explain the first one.
    +------------------------------------------------------------------------------+ error #10056: symbol "stopWatchModeInit" redefined: first defined in
    "./StopWatchMode-new.obj"; redefined in "./StopWatchMode.obj" +------------------------------------------------------------------------------+ Yes I eliminated these errors by getting rid of the "-new.obj" files. +------------------------------------------------------------------------------+ warning #10247-D: creating output section ".stack" without a SECTIONS specification +------------------------------------------------------------------------------+ This means you should be concerned about two problems. One, you are not setting the size of the stack with the option --stack=size . Two, the .stack section
    is allocated to memory according the default settings of the linker,
    which is probably wrong. +------------------------------------------------------------------------------+ This is in the linker command line: -heap_size=255 --stack_size=255 But this does not help with the "SECTIONS" tag, and I'm not sure where
    to set this. +------------------------------------------------------------------------------+ warning #10229-D: output section ".data" refers to load symbol "BAKMEM2_L" and hence cannot be compressed; compression "rle" is ignored +------------------------------------------------------------------------------+
    I recommend you ignore this one for now. Everything will still work. But it takes up a bit more memory than is possible. +------------------------------------------------------------------------------+ Sounds like a broken reference. +------------------------------------------------------------------------------+ undefined first referenced symbol in file ADCMEM0 ./TempSensorMode.obj +------------------------------------------------------------------------------+ That says the file TempSensorMode.c uses the symbol ADCMEM0 (probably data), but there is no definition of that symbol. You have to supply the code which defines this symbol. Perhaps those symbols are defined in libraries that you forgot to use in the link. +------------------------------------------------------------------------------+ SFR_16BIT(ADCMEM0); /* ADC Conversion Memory 0 */ Is defined in file "msp430fr4133.h" And this line is in all of the appropriate files: #include <msp430fr4133.h> All of the files in this project are unmodified, that is they are in the original "Out Of Box MSP430FR4133" form. The only file I changed was "main.c" with the following line: // Amended by JBG [Monday 02 May 2016 19:15:44] code:(*count)=-1; (*count)=0; --(*count); The reason for this amendment is that the compiler would complain about a sign change and error out. And I know from experience that the result of such sign change operations usually produces undesired results. +------------------------------------------------------------------------------+ Where you able to compile and link an unmodified OutOfBox_MSP430FR4133 example from MSPWare using the v4.3.8 compiler? +------------------------------------------------------------------------------+ The short answer is no. The project files are mostly unmodified except where I indicated that I made changes. This is definitely a “linker” communication problem. As I have not changed the tool that links, just the one that compiles. I could tolerate the errors you got in your listing if I could get them. Short of purchasing a new computer I must use what I’ve got.
    Your thoughts welcome. Thanks J.B.G.
  • James Grieger said:
    This is in the linker command line: -heap_size=255 --stack_size=255 But this does not help with the "SECTIONS" tag, and I'm not sure where
    to set this.

    So you do set the size of the stack.  Do you also have a line in the linker command file similar to ...

        .stack > MEMORY_RANGE

    That tells the linker which memory range to use for allocating the stack.

    James Grieger said:
    That says the file TempSensorMode.c uses the symbol ADCMEM0 (probably data), but there is no definition of that symbol. You have to supply the code which defines this symbol. Perhaps those symbols are defined in libraries that you forgot to use in the link. +------------------------------------------------------------------------------+ SFR_16BIT(ADCMEM0); /* ADC Conversion Memory 0 */ Is defined in file "msp430fr4133.h" And this line is in all of the appropriate files: #include <msp430fr4133.h>

    I suspect something has gone wrong during the preprocessing of thie file.  I'm not sure what could be wrong.  But I have a suggestion on how you can figure it out.  Use the option --gen_acp_raw to create a listing file that shows your source code both before and after the preprocessing step.  Read about it in the MSP430 compiler manual.  With that information, you can probably work out why that variable does not get defined.

    Thanks and regards,

    -George

  • James Grieger said:
    The short answer is no. The project files are mostly unmodified except where I indicated that I made changes. This is definitely a “linker” communication problem. As I have not changed the tool that links, just the one that compiles.

    Could you zip-up an attach a copy of the CCS project which is causing you problems?

    That would make it easier to investigate what is going wrong.

  • Greetings;

    I started the IDE up today, tuned some of the compile flags and got this:

    Building target: OutOfBox_MSP430FR4133.out
    Invoking: MSP430 Linker
    "/opt/ti/ccsv6/tools/compiler/msp430_4.3.8/bin/cl430"
    -vmsp
    --abi=eabi
    --code_model=small
    --data_model=small
    -O0
    --opt_for_speed=1
    -g
    --define=__MSP430FR4133__
    --set_error_limit=100
    --section_sizes=on
    --display_error_number
    --silicon_errata=CPU21
    --silicon_errata=CPU22
    --silicon_errata=CPU40
    -z -m"OutOfBox_MSP430FR4133.map"
    --heap_size=255
    --stack_size=255
    --cinit_hold_wdt=on
    -i"/opt/ti/ccsv6/ccs_base/msp430/include"
    -i"/opt/ti/ccsv6/tools/compiler/msp430_4.3.8/lib"
    -i"/opt/ti/ccsv6/tools/compiler/msp430_4.3.8/include"
    -i"/opt/ti/ccsv6/ccs_base/msp430/include_gcc"
    --reread_libs
    --warn_sections
    --display_error_number
    --xml_link_info="OutOfBox_MSP430FR4133_linkInfo.xml"
    -o "OutOfBox_MSP430FR4133.out"
    "./StopWatchMode.obj"
    "./TempSensorMode.obj"
    "./hal_LCD.obj"
    "./main.obj"
    "./driverlib/MSP430FR2xx_4xx/adc.obj"
    "./driverlib/MSP430FR2xx_4xx/crc.obj"
    "./driverlib/MSP430FR2xx_4xx/cs.obj"
    "./driverlib/MSP430FR2xx_4xx/eusci_a_spi.obj"
    "./driverlib/MSP430FR2xx_4xx/eusci_a_uart.obj"
    "./driverlib/MSP430FR2xx_4xx/eusci_b_i2c.obj"
    "./driverlib/MSP430FR2xx_4xx/eusci_b_spi.obj"
    "./driverlib/MSP430FR2xx_4xx/framctl.obj"
    "./driverlib/MSP430FR2xx_4xx/gpio.obj"
    "./driverlib/MSP430FR2xx_4xx/lcd_e.obj"
    "./driverlib/MSP430FR2xx_4xx/pmm.obj"
    "./driverlib/MSP430FR2xx_4xx/rtc.obj"
    "./driverlib/MSP430FR2xx_4xx/sfr.obj"
    "./driverlib/MSP430FR2xx_4xx/sysctl.obj"
    "./driverlib/MSP430FR2xx_4xx/timer_a.obj"
    "./driverlib/MSP430FR2xx_4xx/tlv.obj"
    "./driverlib/MSP430FR2xx_4xx/wdt_a.obj"
    "../lnk_msp430fr4133.cmd"
    -l"libc.a"
    <Linking>
    warning #10202-D: no suitable entry-point found; setting to 0
    FILE: OutOfBox_MSP430FR4133.out
    CODE  size (bytes):      1722
    CONST size (bytes):       172
    DATA  size (bytes):         0

    Finished building target: OutOfBox_MSP430FR4133.out
     
    **** Build Finished ****

    But the "OutOfBox_MSP430FR4133.out" file is 59Kb in length and the MSP430FR4133 only has 16Kb. I'm happy that it compiled but the file size and the missing entry point are a new mystery.

    Do you know what doc. number is for the V4.3.8 compiler?

    Thanks for responding.  J.B.G.

  • James Grieger said:
    But the "OutOfBox_MSP430FR4133.out" file is 59Kb in length and the MSP430FR4133 only has 16Kb.

    The OutOfBox_MSP430FR4133.out file is in ELF format and contains some data which isn't loaded onto the target. To see the memory usage on the target one way is to open the "Memory Allocation" view in CCS. E.g. I got the following for the OutOfBox_MSP430FR4133 example which show that only 39% of the available FRAM space is actually used:

    The text .map file produced by the linker also reports the memory usage in the different memory sections in the target.

    James Grieger said:
    I'm happy that it compiled but the file size and the missing entry point are a new mystery.

    The missing entry point is a problem, because with a C project the entry point should be defined in the C run time library. I think the missing entry point means the program wouldn't run correctly. Not sure what is causing the missing entry point.

    Looking at the include paths reported by the linker shows both the TI compiler device directory /opt/ti/ccsv6/ccs_base/msp430/include and the GCC compiler device directory /opt/ti/ccsv6/ccs_base/msp430/include_gcc:

     

    James Grieger said:
    -i"/opt/ti/ccsv6/ccs_base/msp430/include"
    -i"/opt/ti/ccsv6/tools/compiler/msp430_4.3.8/lib"
    -i"/opt/ti/ccsv6/tools/compiler/msp430_4.3.8/include"
    -i"/opt/ti/ccsv6/ccs_base/msp430/include_gcc"
    Did you add the /opt/ti/ccsv6/ccs_base/msp430/include_gcc directory?

    [Not sure if the include_gcc directory is causing a problem, but looking at other examples for the TI compiler that directory is in the list of includes]

  • James Grieger said:
    Do you know what doc. number is for the V4.3.8 compiler?

    Do you mean the Literature Number?

    The MSP430 Assembly Language Tools v 4.3 User's Guide is SLAU131I December 2013

    The MSP430 Optimizing C/C++ Compiler v 4.3 User's Guide is SLAU132I December 2013

    These old versions don't seem to be on the TI website, but found archive copies at:


  • The OutOfBox_MSP430FR4133.out file is in ELF format and contains some data which isn't loaded onto the target. To see the memory usage on the target one way is to open the "Memory Allocation" view in CCS. E.g. I got the following for the OutOfBox_MSP430FR4133 example which show that only 39% of the available FRAM space is actually used:


    This is confermed; I got the same/similar results of 39%.


    The missing entry point is a problem, because with a C project the entry point should be defined in the C run time library. I think the missing entry point means the program wouldn't run correctly. Not sure what is causing the missing entry point.


    This "Entry Point" error went away after I reloaded the project with fresh files, not sure what caused that but the new reload of files eliminated it as I made absolutely no changes to any of the files. However the compiler is still complaining about the sign change of "[ (*count)=-1; ]". As you can see in the Zip'ed compile output.


    Looking at the include paths reported by the linker shows both the TI compiler device directory /opt/ti/ccsv6/ccs_base/msp430/include and the GCC compiler device directory /opt/ti/ccsv6/ccs_base/msp430/include_gcc:


    After reloading the project these paths were removed and I did not add them.

    /cfs-file/__key/communityserver-discussions-components-files/81/1033.Build_2D00_V4.3.8.log.zip

    I'm not sure if the above link works, I'm not sure how to attach files to forum letters.

    Thanks J.B.G.

  • James Grieger said:
    However the compiler is still complaining about the sign change of "[ (*count)=-1; ]". As you can see in the Zip'ed compile output.

    Looking at the code, the compiler is reporting a valid warning since the code is storing the value -1 into an unsigned char.

    To avoid the warning the example code should have been written as:

                        (*count)=255;
    


  • This is a “Conclusion Post”. If you have this problem this may or may-not help.

    Of all the errors encountered, it seems a fresh install may be the conclusion.


    Machine makeup:

    uname -s kernel name – “Linux”

    uname -n hostname – “linux-13-2”

    uname -r kernel release – “3.16.7-35-default”

    uname -v kernel version – “#1 SMP Sun Feb 7 17:32:21 UTC 2016 (832c776)”

    uname -m machine hardware name – “i686”

    uname -p processor type – “athlon”

    uname -i hardware platform – “i386”

    uname -o operating system – “GNU/Linux”

    Processor makeup: “From /proc/cpuinfo”.

    processor : 0

    vendor_id : AuthenticAMD

    cpu family : 6

    model : 10

    model name : AMD Athlon(tm) XP 3000+

    stepping : 0

    cpu MHz : 2058.954

    cache size : 512 KB

    physical id : 0

    siblings : 1

    core id : 0

    cpu cores : 1

    apicid : 0

    initial apicid : 0

    fdiv_bug : no

    f00f_bug : no

    coma_bug : no

    fpu : yes

    fpu_exception : yes

    cpuid level : 1

    wp : yes

    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36

    mmx fxsr sse syscall mmxext 3dnowext 3dnow

    bogomips : 4117.90

    clflush size : 32

    cache_alignment : 32

    address sizes : 34 bits physical, 32 bits virtual

    power management : ts


    Now addressing the issues:


    George:

    Looking at the code, the compiler is reporting a valid warning since the code is storing the value

    -1 into an unsigned char.

    To avoid the warning the example code should have been written as:

    (count)=255;


    I will do that; altho the original programmer should have done this.


    George:

    So you do set the size of the stack.  Do you also have a line in the linker command file similar to…

    “.stack > MEMORY_RANGE”
    That tells the linker which memory range to use for allocating the stack.

    I could not find any reference to “.stack range” anywere.


    George:

    --gen_acp_raw


    I tried this option: the compiler ignored it and the linker rejected it,. Could be the tool version.

    And now my final option:


    This is a P3 processor as such it can not run the tool set version of 4.4.5.

    The abnormal termination is due to the lack of the SSE2 extensions in the processor.

    The lowest tool revision level that can be used with a P3 processor is the

    MSP430 4.4.4 compiler version. And this is an unvalidated assumption.

    As of version 4.4.5 the tool chain was optimized for the P4, maybe higher.

    However there are only three tools that are problematic, they are:

    “asm430”, “lnk430”, “ofd430”.

    You can use the V4.4.5 version if you also have the 4.4.4 version installed, but you have to hack it.

    Here's the hack that I used.

    (1). Rename the three offending binaries by adding a “-1” to the file name.

    (2). Create links in the 4.4.5 version directory that point to the binaries in the

    4.4.4 version directory.

    This has worked on my system, there’s no guarantee that it will work on any other.

    Admittedly this is a hack and as hacks go:

    USE AT YOUR OWN RISK I ASSUME NO CLAIM OF RISK OR DAMAGE TO YOUR SYSTEM IF YOU PERFORM ANY OF THESE ACTIONS.

    The only drawback I see is the lack of the added functionality of version 4.4.5 is lost because of the use of the older tools. Other then upgrading with another host this is the solution I used.

    The computer is'ent broken it's just old and I'm not ready to throw it off the side of the boat yet.

    Sometimes entropy is natural; sometimes entropy is man-made.

    I had to remove my current installation because CCS6 would NOT let me downgrade the tool-set.

    I did not install any compilers during the initial install, I installed the MSP430 compiler tools

    “One At a Time” starting with version 4.4.0 until I got to version 4.4.5 at which time the

    “Abnormal Termination” and “Illegal Instruction” errors occurred. I also noted that some of the

    other tools for the other processors also produced these errors. I'm not sure of these version breaks so your on your own on these, but feel free to post your troubles if you want.

    BTW This is a OpenSuSE 13.2 (32 bit) OS.


    This is the compiler command options as set in the IDE.

    -vmspx --abi=eabi --use_hw_mpy=none --include_path="/opt/ti/ccsv6/ccs_base/msp430/include" --include_path="/home/engineer/workspace_v6_1/OutOfBox_MSP430FR4133/driverlib/MSP430FR2xx_4xx" --include_path="/opt/ti/ccsv6/tools/compiler/ti-cgt-msp430_4.4.5/include" --advice:power="all" --advice:hw_config=all -g --define=__MSP430FR4133__ --display_error_number --diag_warning=225 --diag_wrap=off --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --printf_support=minimal

    This is the linker command options as set in the IDE.

    -vmspx --abi=eabi --use_hw_mpy=none --advice:power="all" --advice:hw_config=all -g --define=__MSP430FR4133__ --display_error_number --diag_warning=225 --diag_wrap=off --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --printf_support=minimal -z -m"OutOfBox_MSP430FR4133.map" --stack_size=160 --heap_size=160 --cinit_hold_wdt=on -i"/opt/ti/ccsv6/ccs_base/msp430/include" -i"/opt/ti/ccsv6/tools/compiler/ti-cgt-msp430_4.4.5/lib" -i"/opt/ti/ccsv6/tools/compiler/ti-cgt-msp430_4.4.5/include" --reread_libs --display_error_number --warn_sections --issue_remarks --emit_warnings_as_errors --diag_wrap=off --xml_link_info="OutOfBox_MSP430FR4133_linkInfo.xml" --use_hw_mpy=none --rom_model –unused_section_elimination=on

    This is the hex utility command options as set in the IDE.

    --memwidth=8 --romwidth=8 –ti_txt


    Thanks for the responses; I suppose there is no chance of TI recompiling the tools for a lesser machine since most computers are forcefully being upgraded by the push for faster/better.. But even these machines will be tossed off the side of the boat eventually. Maybe (10) years. what a wast of money. Thanks Bill.

    Thanks J.B.G.