Wayne Uroda wrote:
> The issue was with line 73 of the makefile:
>
> PREFIX          = $(shell pwd -W)/build/installed
>
> What is the point of this line? On my system, under cygwin, pwd does not
> support a -W option. I simply changed this line to read:
>
> PREFIX          = $(INSTALLDIR)
Yes.

> Following this everything was pretty straightforward and I used the
> commands below to build MSP430X support.
>
> export
> CVSROOT=:pserver:[email protected]:/cvsroot/mspgcc
> export CVS_RSH=ssh
> cvs login
> cvs co -r MSP430X gcc
> cvs co -r MSP430X packaging
> cvs co -r MSP430X msp430-libc
> cd packaging/
> make folders
> make binutils
> make gcc
> make msp430-libc-build
> make msp430-libc-install
Can we add this short HowTo to wiki?

> After that I tried to build some source code which currently builds with
> the latest release of MSPGCC. I get the following errors at link time (I
> have removed file names for clarity):
>
> : undefined reference to `__MPY'
> : undefined reference to `__MPYS'
> : undefined reference to `__MAC'
> : undefined reference to `__OP2'
> : undefined reference to `__RESLO'
> : undefined reference to `__RESHI'
>
> It is probable that MACS and SUMEXT are also undefined. I have checked
> and mpy.h is being included by the .c files at compile time.
> The linker command line is
>
> msp430-gcc -MD -nostartfiles -mmcu=msp430x2418 -Wall -O2 -g
> -fomit-frame-pointer -Wl,-T linkopt.x -o <output> <input objects>
It's because of -nostartfiles.
I'll try to explain. TI releases 5xxx family with many enhancements. One of 
them - rearranged
peripheral allocation. As a result - multiplier addresses has changed.
In pre-430X versions of mspgcc MPY sfrs was set to absolute addresses by 
assembler '=' directive in
libgcc.s source file and compiler also emits such assignments into generated 
asm sources. Staying
with such strategy leads into compiler source code bloating and into a 
necessarity to have a
distinct library set for mcu's with different sfr allocation. So I decided to 
discard absolute
addresses assignments in libraries and allocate library used sfrs at link time. 
I added weak
declaration of such sfrs into crt430x____.o files, as each of them is build for 
particularly mcu.
with -nostartfiles you discard crt file from linking and those symbols remain 
undefined.

But we can win: add sfr.S file to your project:

#include <io.h>
/***************************************************************
 *      Declare registers used in library routines
 ***************************************************************/
.macro  MAKE_WEAK   name
        .weak   __\name
        .set    __\name, \name
.endm
        MAKE_WEAK   WDTCTL
#if defined (__MSP430_HAS_HW_MUL__)
        MAKE_WEAK   MPY
        MAKE_WEAK   MPYS
        MAKE_WEAK   MAC
        MAKE_WEAK   MACS
        MAKE_WEAK   OP2
        MAKE_WEAK   RESLO
        MAKE_WEAK   RESHI
        MAKE_WEAK   SUMEXT
#if defined (__MSP430_HAS_HW_MUL32__)
        MAKE_WEAK   MPY32L
        MAKE_WEAK   MPY32H
        MAKE_WEAK   MPYS32L
        MAKE_WEAK   MPYS32H
        MAKE_WEAK   MAC32L
        MAKE_WEAK   MAC32H
        MAKE_WEAK   MACS32L
        MAKE_WEAK   MACS32H
        MAKE_WEAK   OP2L
        MAKE_WEAK   OP2H
        MAKE_WEAK   RES0
        MAKE_WEAK   RES1
        MAKE_WEAK   RES2
        MAKE_WEAK   RES3
        MAKE_WEAK   MPY32CTL0
#endif
#endif

compile it with
gcc -x assembler-with-cpp -mmcu=msp430x2418 sfr.S -o sfr.o
and link into your project.
>
> 1. Can somebody please explain or fix the 'pwd -W' call in the
> packaging/makefile?
fixed.
> 2. Can anybody help with the multiplier issue? I can define the symbols
> myself in the link file but I want to know if this is a symptom of

> something deeper.
> 3. My username is wayneuroda . Can somebody please give me access to
> change the wiki?
Chris?


Btw, I changed a little prologue/epilogue generation again. Now no registers 
saved in prologue and
no prologue generated if function never returns. So, update your sources and 
rebuild compiler again ;)

--
Regards,
   Sergey A. Borshch            mailto: [email protected]
     SB ELDI ltd. Riga, Latvia


Reply via email to