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.

MSP430-GCC-OPENSOURCE: Undefined reference to `__mspabi_divi'

Part Number: MSP430-GCC-OPENSOURCE
Other Parts Discussed in Thread: MSP430FR2100,

I am trying to use MSP430-GCC-OPENSOURCE to compile code targeting the MSP430FR2100. I have successfully installed the compiler, compiled some c-code with -nostdlib, but now I am trying to compile code that requires standard library functions (I removed the -nostdlib flag). I am getting the following errors:

undefined reference to `strlen'

undefined reference to `__mspabi_remi'

undefined reference to `mspabi_divi'

So it looks like the tools are not linking the correct library function calls. If I understood correctly, the full installer should contain newlib. Is there a trick to helping the compiler/linker find the right files?

For reference, I have installed msp430-gcc-full-linux-x64-installer-9.2.0.0.run

  • The compiler should know where to find those libraries. Either there is a problem with your compiler options or the installation. 9.2 works fine for me.

  • Thanks for the quick response,

    I'm not sure how the installation could be messed up. I simply ran the installer.run and it completed without errors, and I added to my PATH the toolchain/bin directory. Are there any additional steps required?

    For compiler options, I have: -Wall -O2 -c -fno-exceptions -I ./ -o main.o main.c

    For linker options, I have: --gc-sections -T msp430.ld -Map test.map -N -o test.elf boot_rom.o main.o

    Anything missing or look obviously wrong?

  • Obviously wrong is no definition of the CPU used. That is required so that the compiler knows where to find things. The linker needs it so it can get the correct .ld file. msp430fr2100.ld in this case. I usually use a makefile.

    GCC_DIR = /usr/ti/gcc/bin
    SUPPORT_FILE_DIRECTORY = /usr/ti/gcc/include
    CC = $(GCC_DIR)/msp430-elf-gcc
    CFLAGS = -mmcu=${CPU}  -Wall -g -Os -I $(SUPPORT_FILE_DIRECTORY) -ffunction-sections
    LFLAGS =   -Wl,--gc-sections -mmcu=${CPU} -g -L $(SUPPORT_FILE_DIRECTORY) -mrelax
    
    
    etc.
  • Okay, this got me a little bit further, but now I'm getting "msp430-elf-ld: unrecognised emulation mode: relax"

  • You must be invoking the linker directly, which might be the root of your problem. My LFLAGS is set up to pass to gcc rather than ld. The big flag telling you that is the "-Wl," which is magic incantation telling gcc to pass what follows to ld.

    In general, you want to let gcc figure out what options and search paths to feed to ld unless you have some very specific requirements.

  • Okay! That helped. Now I can complete a build. The only thing that seems to be not working correctly is establishing and keeping the RESETVEC at 0xfffe. It's defaulting to zero, even though msp430fr2100.ld should be reserving it at 0xfffe. My boot_rom.s uses the same convention as before: .section ".resetvec", "a" right before __start:

    Any ideas on this issue?

  • The C runtime sets the reset vector so you shouldn't be doing anything to it.

    Unless you are trying to bypass the C startup code in which case you have to tell the compiler to not include it.

  • It's more for programming purposes. I need something that tells the programmer to write the correct start address to reset-vector address 0xfffe. This is before C runtime because it's part of the CPU reset hardware logic. I could hard code it...but this used to work in my -nostdlib build.

    I can see "__reset_vector" in the object dump file, but its set to address 0x00000000. On my previous -nostdlib builds, I would also see "__reset_vector" in the object dump file, and the address would be correctly set to 0x0000fffe. Part of my programming process is to convert the elf into an ihex file, and this needs to contain data to be programmed into 0xfffe. As of now, it does not and I'm not sure why.

  • It has to be something that you are doing because I have converted from .elf to .hex and all of the vectors show up.

  • I don't doubt that.

**Attention** This is a public forum