EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

MSPGCC and MSP430X

Started by linked82 May 9, 2008
Hi all,

Does have mspgcc compiler support for MSP430X cores? If not, does
exist any patch to make it work?

Best Regards.

Beginning Microcontrollers with the MSP430

Hi
Have you ported linux to msp430x series and i followed building mspgcc
documents from TI in that chapter 11 i was able to compile only
bin-utils and i could not get the sources from cvs and rest gcc
msp430-libc are pending.please share your views and waiting for your reply

Regards
Umamahesh

--- In m..., "mahesh_ecem" wrote:
>
> Hi
> Have you ported linux to msp430x series and i followed building mspgcc
> documents from TI in that chapter 11 i was able to compile only
> bin-utils and i could not get the sources from cvs and rest gcc
> msp430-libc are pending.please share your views and waiting for your
reply
>
> Regards
> Umamahesh
>

Hi

I don't quite understand the previous post so I'll post my own
question in this thread is it relates to mspgcc and the MSP430X
architecture.

I have downloaded the mspgcc binary from 20080529 to my WinXP machine
with Cygwin (cygwin1.dll version 1005.25.0.0) already in place.

My task is to port a software written for an F149 device to an F2419
device. The software consists of a bootloader and two program banks
for application software. The reset vector points at the bootloader
which issues a "BR " to jump to the start of the currently
active program bank.

For the new device the locations of the code will be:
Bootloader @ 0x10000
Application bank 0 @ 0x2100
Application bank 1 @ 0x12400

In order to jump to the start of application bank 1 I have changed the
original code (inline assembler) from "BR 0x8300" to "BRA 0x12400".
When compiling this the msp430-gcc generates the following:

msp430-gcc -mmcu=msp430x2419 -O2 -Wall -g --std=gnu99 -I includes -I
c:/Program/
mspgcc/msp430/include -D SOFTWARE=BOOTLOADER -nostdlib -c -o boot.o
boot.c
boot.c: In function `main':
boot.c:12: warning: unused variable `applicationMain'
/cygdrive/c/Temp/ccrysUIw.s: Assembler messages:
/cygdrive/c/Temp/ccrysUIw.s:136: Error: unknown opcode `bra'
/cygdrive/c/Temp/ccrysUIw.s:143: Error: unknown opcode `bra'
make: *** [boot.o] Error 1

The code:

int main (void) {
uint8_t bank;

WDTCTL = WDTPW + WDTHOLD; // Stop WDT
bank = ReprogGetActiveBank();

if (bank == BANK1)
{
asm("BRA #0x12400");
}

asm ("BRA #0x2100");
}
Am I missing something or isn't mspgcc compatible with the MSP430X
architecture?
There are linker scripts included for MSP430F2419 in the distribution
I downloaded.

Regards
Anders
Instead of "inline assembly", you may want to try "inline hex code".
The hex code for BRA #0x12400 is 0x0180 0x2400.
The hex code for BRA #0x2100 is 0x0080 0x2100.

--- In m..., "andersryl" wrote:
>
> --- In m..., "mahesh_ecem" wrote:
>
> Hi
>
> I don't quite understand the previous post so I'll post my own
> question in this thread is it relates to mspgcc and the MSP430X
> architecture.
>
> I have downloaded the mspgcc binary from 20080529 to my WinXP
> machine with Cygwin (cygwin1.dll version 1005.25.0.0) already
> in place.
>
> My task is to port a software written for an F149 device to an
> F2419 device. The software consists of a bootloader and two
> program banks for application software. The reset vector points
> at the bootloader which issues a "BR " to jump to the
> start of the currently active program bank.
>
> For the new device the locations of the code will be:
> Bootloader @ 0x10000
> Application bank 0 @ 0x2100
> Application bank 1 @ 0x12400
>
> In order to jump to the start of application bank 1 I have
> changed the original code (inline assembler) from "BR 0x8300"
> to "BRA 0x12400". When compiling this the msp430-gcc generates
> the following:
>
> msp430-gcc -mmcu=msp430x2419 -O2 -Wall -g --std=gnu99 -I
> includes -I c:/Program/
> mspgcc/msp430/include -D SOFTWARE=BOOTLOADER -nostdlib
> -c -o boot.o
> boot.c
> boot.c: In function `main':
> boot.c:12: warning: unused variable `applicationMain'
> /cygdrive/c/Temp/ccrysUIw.s: Assembler messages:
> /cygdrive/c/Temp/ccrysUIw.s:136: Error: unknown opcode `bra'
> /cygdrive/c/Temp/ccrysUIw.s:143: Error: unknown opcode `bra'
> make: *** [boot.o] Error 1
>
> The code:
>
> int main (void) {
> uint8_t bank;
>
> WDTCTL = WDTPW + WDTHOLD; // Stop WDT
> bank = ReprogGetActiveBank();
>
> if (bank == BANK1)
> {
> asm("BRA #0x12400");
> }
>
> asm ("BRA #0x2100");
> }
> Am I missing something or isn't mspgcc compatible with the
> MSP430X architecture?
> There are linker scripts included for MSP430F2419 in the
> distribution I downloaded.
>
> Regards
> Anders
>

Hi Folks,

I just started working with MSP430F427 MCU for my project. I am using Softbaugh evaluation board ES427. Can any one send me some sample codes particularly how to read SD16 using A0 channel and display its data to LCD?

I shall be very much thankful for your kind help.

Regards,

-Hassan


--- In m..., "old_cow_yellow"
wrote:
>
> Instead of "inline assembly", you may want to try "inline hex code".
> The hex code for BRA #0x12400 is 0x0180 0x2400.
> The hex code for BRA #0x2100 is 0x0080 0x2100.
>

Thanks for the suggestion!

I changed
asm ("BRA #0x12400"); to
asm "#0x0180 #0x2400");
and it worked!

What is the status of the MSPGCC, really?
How many other quirks are there?
The documentation is not exactly up-to-date.

I shouldn't complain about someones voluntary efforts in creating a
free compiler for the MSP430 family. It is a great effort but I have
to look at it from a cost perspective and paying for a compiler might
be a better option.

If it doesn't even handle the new instructions of the MSP430X I think
I will switch to a commercial compiler, i.e. IAR.

Regards
Anders
I use assembly and cannot even find an assembler that emit the correct
hex code. I tried the free KickStart version of IAR. It does not
generate hex codes correspond to my assembly codes.

--- In m..., "andersryl" wrote:
>
> --- In m..., "old_cow_yellow"
> wrote:
> >
> > Instead of "inline assembly", you may want to try "inline hex code".
> > The hex code for BRA #0x12400 is 0x0180 0x2400.
> > The hex code for BRA #0x2100 is 0x0080 0x2100.
> > Thanks for the suggestion!
>
> I changed
> asm ("BRA #0x12400"); to
> asm "#0x0180 #0x2400");
> and it worked!
>
> What is the status of the MSPGCC, really?
> How many other quirks are there?
> The documentation is not exactly up-to-date.
>
> I shouldn't complain about someones voluntary efforts in creating a
> free compiler for the MSP430 family. It is a great effort but I have
> to look at it from a cost perspective and paying for a compiler might
> be a better option.
>
> If it doesn't even handle the new instructions of the MSP430X I think
> I will switch to a commercial compiler, i.e. IAR.
>
> Regards
> Anders
>

What version of IAR kickstart are you using? For the full toolet 430X
support only really got going at version 4.10. I have some thousands of
units delivered that use 430X code from the compiler with some assembler
inserts (using extended instrutions). The code is working as well as it did
on the old 149 target processor using the 430 instruction set.

Regards

Ian

www.satamatics.com

2008/6/5 old_cow_yellow :

> I use assembly and cannot even find an assembler that emit the correct
> hex code. I tried the free KickStart version of IAR. It does not
> generate hex codes correspond to my assembly codes.
>
> --- In m..., "andersryl" wrote:
> >
> > --- In m..., "old_cow_yellow"
> > wrote:
> > >
> > > Instead of "inline assembly", you may want to try "inline hex code".
> > > The hex code for BRA #0x12400 is 0x0180 0x2400.
> > > The hex code for BRA #0x2100 is 0x0080 0x2100.
> > >
> >
> > Thanks for the suggestion!
> >
> > I changed
> > asm ("BRA #0x12400"); to
> > asm "#0x0180 #0x2400");
> > and it worked!
> >
> > What is the status of the MSPGCC, really?
> > How many other quirks are there?
> > The documentation is not exactly up-to-date.
> >
> > I shouldn't complain about someones voluntary efforts in creating a
> > free compiler for the MSP430 family. It is a great effort but I have
> > to look at it from a cost perspective and paying for a compiler might
> > be a better option.
> >
> > If it doesn't even handle the new instructions of the MSP430X I think
> > I will switch to a commercial compiler, i.e. IAR.
> >
> > Regards
> > Anders
> >
Does your assembler translate "MOV 0(R4),R15" into "0x441F, 0x0000" or
"0x442F"?
Does your assembler translate "PUSH.W #4" into "0x1222" or "0x1230,
0x0004"?

Call me a contemptuous, egoistic, self-centered dictator. When I write
code in assembly, I expect the assembler to generate the exact hex
code I want. Not some almost equivalent code that has different side
effect. Not some similar code that takes longer/shorter clocks to
execute, or takes more/less code space. I do not want the assembler to
work around bugs, especially no-longer-existing historical bugs. I do
not want the assembler to increase/decrease the CPU cycles or code
size. I only want it to translate what I wrote.

--- In m..., "Ian Okey" wrote:
>
> What version of IAR kickstart are you using? For the full toolet 430X
> support only really got going at version 4.10. I have some thousands of
> units delivered that use 430X code from the compiler with some assembler
> inserts (using extended instrutions). The code is working as well
as it did
> on the old 149 target processor using the 430 instruction set.
>
> Regards
>
> Ian
>
> www.satamatics.com
>
> 2008/6/5 old_cow_yellow :
>
> > I use assembly and cannot even find an assembler that emit the correct
> > hex code. I tried the free KickStart version of IAR. It does not
> > generate hex codes correspond to my assembly codes.
> >
> > --- In m..., "andersryl" wrote:
> > >
> > > --- In m..., "old_cow_yellow"
> > > wrote:
> > > >
> > > > Instead of "inline assembly", you may want to try "inline hex
code".
> > > > The hex code for BRA #0x12400 is 0x0180 0x2400.
> > > > The hex code for BRA #0x2100 is 0x0080 0x2100.
> > > >
> > >
> > > Thanks for the suggestion!
> > >
> > > I changed
> > > asm ("BRA #0x12400"); to
> > > asm "#0x0180 #0x2400");
> > > and it worked!
> > >
> > > What is the status of the MSPGCC, really?
> > > How many other quirks are there?
> > > The documentation is not exactly up-to-date.
> > >
> > > I shouldn't complain about someones voluntary efforts in creating a
> > > free compiler for the MSP430 family. It is a great effort but I have
> > > to look at it from a cost perspective and paying for a compiler
might
> > > be a better option.
> > >
> > > If it doesn't even handle the new instructions of the MSP430X I
think
> > > I will switch to a commercial compiler, i.e. IAR.
> > >
> > > Regards
> > > Anders
> > >
> >
> >
> >
> >
> >
> >
> >
> >
Hi,

> Does your assembler translate "MOV 0(R4),R15" into "0x441F, 0x0000" or
> "0x442F"?
> Does your assembler translate "PUSH.W #4" into "0x1222" or "0x1230,
> 0x0004"?
>
> Call me a contemptuous, egoistic, self-centered dictator. When I write
> code in assembly, I expect the assembler to generate the exact hex
> code I want. Not some almost equivalent code that has different side
> effect. Not some similar code that takes longer/shorter clocks to
> execute, or takes more/less code space. I do not want the assembler to
> work around bugs, especially no-longer-existing historical bugs. I do
> not want the assembler to increase/decrease the CPU cycles or code
> size. I only want it to translate what I wrote.

Sorry to be a stick in the mud, but the MSP430 manuals do *not* prescribe
how to map an assembler-level mnemonic to machine code in a 1:1 manner.

PUSH.W #0 is a prime example. There are two valid encodings for this, yet
there is no way to tell *any* assembler which one to pick.

There is *nowhere* in the manual that says "Assemblers must..." that I can
find, the CG is only described as a way of generating frequently-used
constants.

PUSH.W #4 is, as you say, an interesting case.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors


The 2024 Embedded Online Conference