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.

undefined reference

Other Parts Discussed in Thread: MSP430G2553

Hi

I have use msp430 to develop product until a few year. I use free compiler with IDE CodeBlocks.

I use compiler mspgcc version is 4.6.3 20120301, this compiler is free software.

Today, I update my compiler. The new version is 5.3.0.219. 

Then, I recompile my old example program to test, the IDE message dailog show:

main.c|| undefined reference to `WDTCTL'|
main.c|| undefined reference to `CALBC1_1MHZ'|
main.c|| undefined reference to `BCSCTL1'|
main.c|| undefined reference to `CALDCO_1MHZ'|
main.c|| undefined reference to `DCOCTL'|
main.c|| undefined reference to `P1DIR'|
main.c|| undefined reference to `TA0CTL'|
main.c|| undefined reference to `TA0CCR0'|
main.c|| undefined reference to `TA0CCTL0'|

So, I check head file msp430g2553.h, I find something disappear.

for example, in old vision, head file has some register address as:

#define WDTCTL_               0x0120    /* Watchdog Timer Control */

#define P1IN_                 0x0020    /* Port 1 Input */

#define P1DIR_                0x0022    /* Port 1 Direction */

But, in new vision has no sets !

and the Interrupt Vectors are different with old version !

I don't want go back to old version, how could I do ?

  • I use CCS [6.1.0], and there the register definitions are resolved by the linker, not the compiler. (I do recall a time when they were #define-s, and I'm not sure when that changed.)

    In my case, the addresses are supplied in "msp430g2553.cmd", which is invoked ("-l") by "lnk_msp430g2553.cmd". If you poke around, maybe you'll find one or more of these files.
  • Thank you!
    I found a file named "msp430g2553_symbols.ld" has register define.

    I have try the command "-S" at compiler, it seen no problem and passed.
    But, the linker has problem.
    compiler message as below:

    msp430-elf-gcc.exe -mmcu=msp430g2553 -S -IC:\Compiler\msp430_gcc\include -c main.c -o obj\main.o
    msp430-elf-gcc.exe -LC:\Compiler\msp430_gcc\include -o bin\LEDBlink.elf obj\main.o -T msp430g2553.ld -l msp430g2553_symbols.ld
    c:/compiler/msp430_gcc/bin/../lib/gcc/msp430-elf/5.3.0/../../../../msp430-elf/bin/ld.exe:obj\main.o: file format not recognized; treating as linker script
    c:/compiler/msp430_gcc/bin/../lib/gcc/msp430-elf/5.3.0/../../../../msp430-elf/bin/ld.exe:obj\main.o:1: syntax error
    collect2.exe: error: ld returned 1 exit status
    Process terminated with status 1 (0 minute(s), 0 second(s))
    2 error(s), 0 warning(s) (0 minute(s), 0 second(s))

    the command "-l" has no effect ?
  • Sorry I should have been more specific.
    The "-l" appears as the last line of my linker script, not in the command line (in the command line, it denotes a library name). I hadn't noticed that feature before, but I'm guessing it's an "include" mechanism for linker scripts.

    Maybe the GCC linker has a similar feature (multiple -T options, e.g.)? Or maybe a way to concatenate linker .ld files? In the worst case, you could just paste the contents of _symbols.ld into the original .ld.
  • You didn't mention why you want -S, but I'm not sure you want to do that here.

    "cc -S -o zzz.o zzz.c" puts the "-S" assembly text into "zzz.o" (and then the linker complains since it's not object code). If you want to just generate the assembly text I think "cc -S -c zzz.c" will put it in "zzz.s".
  • Now I just add one command "-mmcu=msp430g2553" to linker, every thing looks like OK.
    This is compiler message:

    msp430-elf-gcc.exe -mmcu=msp430g2553 -IC:\Compiler\msp430_gcc\include -c main.c -o obj\main.o
    msp430-elf-gcc.exe -LC:\Compiler\msp430_gcc\include -o bin\LEDBlink.elf obj\main.o -mmcu=msp430g2553
    Output file is bin\LEDBlink.elf with size 8.93 KB
    Running project post-build steps
    C:\Compiler\msp430_gcc\bin\msp430-elf-objcopy -O ihex bin\LEDBlink.elf bin\LEDBlink.hex
    cmd /c "C:\Compiler\msp430_gcc\bin\msp430-elf-objdump -S bin\LEDBlink.elf > bin\LEDBlink.asm"
    C:\Compiler\msp430_gcc\bin\msp430-elf-size bin\LEDBlink.elf
    text data bss dec hex filename
    876 16 24 916 394 bin\LEDBlink.elf
    Process terminated with status 0 (0 minute(s), 1 second(s))
    0 error(s), 0 warning(s) (0 minute(s), 1 second(s))

    It looks don't need any "-T" or "-S".

    But the final file is big than old version very much.
    I tried use "-Os" to reduce file size and check the objdump file, I find some problem.
    In objdump file, the function in while loop are disappeared. Maybe I use wrong command ?

    I have no hardware now, when I make sure this problem exist, I will post question in another topic.

    Thank your attention!
  • I'm glad it worked out. I wouldn't have guessed that that feature worked that way.

    I forget which optimizations are in "-Os", but in general I wouldn't be surprised to see the code for some functions inline-d and/or broken up, such that they didn't appear as units any more. Some functions might indeed completely disappear, if the optimizer's analysis concluded they couldn't ever be called.

    Also, don't be too concerned about the raw size of the .ELF file -- the newer compiler may just be putting in more extra stuff (debug information, e.g.) than the old one. The msp430-elf-size output shows what's actually going into the device.
  • Yes, I didn't care the ELF file size. I care the text size.
    I use two version compiler ( 5.3.0.219 and 4.6.3 ) and compile the same source code.
    The compiler message as below:

    -------------- Build: Debug in LEDBlink (compiler: GNU GCC Compiler for MSP430 (HighTec))---------------
    msp430-elf-gcc.exe -mmcu=msp430g2553 -IC:\Compiler\msp430_gcc\include -c main.c -o obj\main.o
    msp430-elf-gcc.exe -LC:\Compiler\msp430_gcc\include -o bin\LEDBlink.elf obj\main.o -mmcu=msp430g2553
    Output file is bin\LEDBlink.elf with size 8.93 KB
    Running project post-build steps
    C:\Compiler\msp430_gcc\bin\msp430-elf-objcopy -O ihex bin\LEDBlink.elf bin\LEDBlink.hex
    cmd /c "C:\Compiler\msp430_gcc\bin\msp430-elf-objdump -S bin\LEDBlink.elf > bin\LEDBlink.asm"
    C:\Compiler\msp430_gcc\bin\msp430-elf-size bin\LEDBlink.elf
    text data bss dec hex filename
    876 16 24 916 394 bin\LEDBlink.elf
    Process terminated with status 0 (0 minute(s), 6 second(s))
    0 error(s), 0 warning(s) (0 minute(s), 6 second(s))

    -------------- Build: Debug in LEDBlink_old (compiler: GNU GCC Compiler for MSP430 (old version))---------------
    msp430-gcc.exe -mmcu=msp430g2553 -IC:\Compiler\msp430_gcc_old\msp430\include -c main.c -o obj\main.o
    msp430-gcc.exe -LC:\Compiler\msp430_gcc_old\msp430\lib\ldscripts -o bin\LEDBlink_old.elf obj\main.o -mmcu=msp430g2553
    Output file is bin\LEDBlink_old.elf with size 6.24 KB
    Running project post-build steps
    C:\Compiler\msp430_gcc_old\bin\msp430-objcopy -O ihex bin\LEDBlink_old.elf bin\LEDBlink_old.hex
    cmd /c "C:\Compiler\msp430_gcc_old\bin\msp430-objdump -S bin\LEDBlink_old.elf > bin\LEDBlink_old.asm"
    C:\Compiler\msp430_gcc_old\bin\msp430-size bin\LEDBlink_old.elf
    text data bss dec hex filename
    328 0 4 332 14c bin\LEDBlink_old.elf
    Process terminated with status 0 (0 minute(s), 0 second(s))
    0 error(s), 0 warning(s) (0 minute(s), 0 second(s))

    The old version code size is small and quick,
    maybe new version sets some command could be save code size, I don't know.

    If I need design product now, I will choose old version.
    For future use, now I will try new version to reduce code size.
  • I don't know the answer, so I won't disagree with you. I use GCC regularly, but not for the MSP430.

    The fact that the .bss and .data also grew may be a clue -- it may be that the newer version is including some "free" extras from the library. The startup code might be one place to look for that.

    Anyway, it sounds as though you have a plan.
  • If you are not using static constructor functions, add the "-minrt" option.

    Another very useful option would be "-flto", but then you have to add "__attribute__((used))" to all interrupt handlers.

  • All right...
    I tried the "-minrt" option in linker, so

    -------------- Build: Debug in LEDBlink (compiler: GNU GCC Compiler for MSP430 (HighTec))---------------
    msp430-elf-gcc.exe -mmcu=msp430g2553 -IC:\Compiler\msp430_gcc\include -c main.c -o obj\main.o
    msp430-elf-gcc.exe -LC:\Compiler\msp430_gcc\include -o bin\LEDBlink.elf obj\main.o -mmcu=msp430g2553 -minrt
    Output file is bin\LEDBlink.elf with size 4.41 KB
    Running project post-build steps
    C:\Compiler\msp430_gcc\bin\msp430-elf-objcopy -O ihex bin\LEDBlink.elf bin\LEDBlink.hex
    cmd /c "C:\Compiler\msp430_gcc\bin\msp430-elf-objdump -S bin\LEDBlink.elf > bin\LEDBlink.asm"
    C:\Compiler\msp430_gcc\bin\msp430-elf-size bin\LEDBlink.elf
    text data bss dec hex filename
    454 0 6 460 1cc bin\LEDBlink.elf

    It looks reduced a half space ! Yes, thank you!
    I open the objdump file and read it, I find many "mspabi_srli" in file,
    If I don't need it, how to eliminate it ?

**Attention** This is a public forum