Jump to content
abecedarian

GCC for MSP430 officially out of beta

Recommended Posts

Great.  Now all they have to do is release the source code.  (Unless they just decided to rebranch version 371 as non-beta, or that announcement preceded the actual release of the non-beta version.  Right now, only the 371 version from May is available for download.)

Share this post


Link to post
Share on other sites

Great.  Now all they have to do is release the source code.  (Unless they just decided to rebranch version 371 as non-beta, or that announcement preceded the actual release of the non-beta version.  Right now, only the 371 version from May is available for download.)

 

Hey guys,

 

It looks like there were some web issues yesterday as @@pabigot mentioned. But it sounds like it is fixed now - see the comments on the bottom of the announcement page on the MSP430 blog: http://e2e.ti.com/blogs_/b/msp430blog/archive/2014/08/18/gcc-for-msp430-microcontrollers-is-ready-for-primetime.aspx

 

Regards,

Katie

Share this post


Link to post
Share on other sites

Hope Red Hat's already pushed the relevant changes upstream.

 

And the answer to that hope is...no.

 

The TI version has added some new directives for code and data placement.  It's also based on something close to but not the same as gcc-4.9.1: it's got some changes to other architectures that also aren't upstream yet, and is missing some patches that are in 4.9.1.  For what any of that's worth.

Share this post


Link to post
Share on other sites

I'm still using yours... Cause it works.

 

For what any of that's worth.  ;)

 

May try Red Hat / TI's some day.  Not yet.  Appreciate the efforts though from all parties.

Share this post


Link to post
Share on other sites

So, I've finally tried this in binary form to get it running quickly.  Initial assessment is that the build and packaging is a bit weird.  Interesting that libmsp430 is included, and in the /bin directory, but that's probably for the GDB agent with firmware update capability.  Overall it's organized better than the beta version.  It's a bit less forgiving than MSPGCC was with iinclude files and LD paths, but I guess that's what Makefiles are for.  The included slau591.pdf manual makes it all pretty clear, and it's standard for GCC anyway.

 

Seems to compile a few basic examples.  Going to hammer on it a bit more when I get some time.

 

There are a few issues with shared library links in some of the included binaries in /bin.  For example, I've found:

 

zborgerd@katana:~$ msp430-elf-gdb 
msp430-elf-gdb: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory
 
zborgerd@katana:~$ ldd `which msp430-elf-gdb` | grep libX11
libX11.so.6 => not found
 
I could manually force the link or redirect it, but I guess the libX11 requirement is simply for an optional GUI component of the GDB agent.  Ditto for wish and some broken tcl components.  I think that someone is going to need to be more careful in packing up these binary builds for end-users, but that's the downside to binaries and shared libraries on lots of different platforms.

 

Beginners should probably stick to MSPGCC for now unless there is an immediate need to upgrade.  For me, I'd like to work on the MSP-EXP430FR5969 launchpad without repeatedly having to BSL a bricked  micro, so this is probably the most logical progression without patching MSPGCC LTS for new FRAM chips.

Share this post


Link to post
Share on other sites

Anyone else notice that the compiler throws a lot of pointless warnings for mcu headers that aren't included as system includes?  For instance:

 

-isystem/opt/ti/gcc/include is fine where -Iopt/ti/gcc/include generates the following:

/opt/ti/gcc/include/msp430fr5969.h:1256:1: warning: 

Share this post


Link to post
Share on other sites

I'm going to guess a lot of the issues are the result of users not using the compiler during beta, and waiting for final. Something regression testing should have revealed? Or maybe, the breaks are intentional so as to wean people from one codebase to another?

Share this post


Link to post
Share on other sites

Normally one would release a production version that's the last beta with minor fixes.  For some reason they've decided to jump from gcc 4.8.0 to gcc 4.9.1 (which improves diagnostics), and add features related to placement of code and data in far memory, without external testers.  (At least not public ones.  TI doesn't talk to me anymore, but they might have selected some others to give it a quick look-over this time.)

Share this post


Link to post
Share on other sites

I've had good luck with the msp430-elf-gcc 4.9.1 version included with CCS 6.  However, it still has issues with the iomacros.h file. They fixed some problems with it but not all. It fails when you try to include <msp430.h> in msp430 assembler files (the ones ending in .S). You can include a fixed version before loading msp430.h and it seems to be happy. (find my hacked up version here: https://gist.github.com/RickKimball/f4786191b8fd88de0338 )

 

I'm sad they are leaving you out of the loop @@pabigot. We all appreciated your attention to detail.  

 

-rick

Share this post


Link to post
Share on other sites

OK, so now I've spent a little more time with it and figured out an issue I was having .. not sure where to get this fixed ..

 

Some of you may know I have a C++ template frameworks called fabooh. It kind of abuses c++ templates to generate some nice small code. It works great with the 4.6.3 msp430-gcc and even with the 4.9 arm-none-eabi-gcc. However with this new version of msp430-elf-gcc it is failing.  I'm getting undefines when I crank up the optimization with -Os.

 

I think I've found the problem. My template names end up being fairly long. In their mangled name state, not very readable. For example:

_ZN7print_tI8eusci_a0ILm9600ELm16000000E8GPIO_PINI9GPIO_PORTILi50ELZ6PAIN_HELZ7PAOUT_HELZ7PADIR_HELZ8PASEL0_HELZ8PASEL1_HELZ8PASELC_HELZ7PAREN_HELZ7PAIFG_HELZ7PAIES_HELZ6PAIE_HEELh1EE9DummyGPIOILh0EEEE5writeEh

Which turns out to be this unmangled:

$ msp430-elf-c++filt -t _ZN7print_tI8eusci_a0ILm9600ELm16000000E8GPIO_PINI9GPIO_PORTILi50ELZ6PAIN_HELZ7PAOUT_HELZ7PADIR_HELZ8PASEL0_HELZ8PASEL1_HELZ8PASELC_HELZ7PAREN_HELZ7PAIFG_HELZ7PAIES_HELZ6PAIE_HEELh1EE9DummyGPIOILh0EEEE5writeEh

print_t<eusci_a0<9600ul, 16000000ul, GPIO_PIN<GPIO_PORT<50, PAIN_H, PAOUT_H, PADIR_H, PASEL0_H, PASEL1_H, PASELC_H, PAREN_H, PAIFG_H, PAIES_H, PAIE_H>, (unsigned char)1>, DummyGPIO<(unsigned char)0> > >::write(unsigned char)

This is a name that works. However I had to chop off some of my template arguments to get it to compile and link properly.  The problem turns out to be that a too long template name will fail. It seems to chop the function name into 2 parts. Then you get undefined variable names.  However, it seems to work fine with -O2 optimization but not with -Os. 

 

This is an example of an old function name that worked fine in msp430-gcc:

$ msp430-c++filt _ZN7print_tI16serial_default_tILm4800ELm1000000E8GPIO_PINILh2E10GPIO_PORT0ILi1ELZ4P1INELZ5P1OUTELZ5P1DIRELZ5P1IFGELZ5P1IESELZ4P1IEELZ5P1SELELZ5P1RENEE14gpio_pincaps_tILb0ELb0ELb0ELb0ELb0ELb0ELb1ELb0EEE9DummyGPIOILh0EEEjmE5writeEh

print_t<serial_default_t<4800ul, 1000000ul, GPIO_PIN<(unsigned char)2, GPIO_PORT0<1, P1IN, P1OUT, P1DIR, P1IFG, P1IES, P1IE, P1SEL, P1REN>, gpio_pincaps_t<false, false, false, false, false, false, true, false> >, DummyGPIO<(unsigned char)0> >, unsigned int, unsigned long>::write(unsigned char)

And this is an example of the failure I get with msp430-elf-gcc 4.9.1:

./blink.o: In function `.Loc.125.5':
blink.cpp:(.text.loop+0x9e): undefined reference to `_ZN7print_tI17serial_eusci_a0_tILm9600ELm16000000E8GPIO_PINI9GPIO_PORTILi50ELZ6PAIN_HELZ7PAOUT_HELZ7PADIR_HELZ8PASEL0_HELZ8PASEL1_HELZ8PASELC_HELZ7PAREN_HELZ7PAIFG_HELZ7PAIES_HELZ6PAIE_HEELh1E14gpio_pincaps_tILb0ELb0ELb0ELb0ELb0ELb0EEE9DummyGPIOILh0EEEE5w'
blink.cpp:(.text.loop+0xa0): undefined reference to `iteEh'
collect2: error: ld returned 1 exit status

As you can see the symbol gets chopped into 2 parts. It seems like the max length for a c++ template name is 256 bytes.  So if you are using C++ templates that result in long mangled names beware of strange failings when you use -Os.

 

-rick

 

[edit: added failing example] BTW: Here is the c++ code:

#include <fabooh.h>

namespace {
  const uint32_t BAUD_RATE=9600;
  //serial_default_t<BAUD_RATE, CPU::frequency, P2_0, NO_PIN> Serial; // xmit only serial
  eusci_a0<BAUD_RATE, CPU::frequency, P2_0, NO_PIN> Serial;
}

static char buff[24] = { "Toggle world!\r\n" };

void setup(void)
{
  LED1::high();
  LED1::setmode_output();
  LED2::low();
  LED2::setmode_output();
  CPU::enable_smclkout();
  Serial.begin(BAUD_RATE);
}


void loop(void)
{
  int16_t cnt = 32760;

  Serial.print(buff);
  do {
    LED1::toggle();
    LED2::toggle();
    delay_msecs(1000/4/2);
    Serial << "cnt=" << _DEC(cnt) << ", 0x" << _HEX(cnt) << ", 0b" << _BIN(cnt) << endl;
    cnt++;
  } while (1);
}

Share this post


Link to post
Share on other sites

If you can create a standalone reproducer, this is the sort of thing that should be reported to gcc: here for the instructions and here for the bug registry.

 

There's only a low probability that it'll get any attention from a maintainer, but there's always a chance and either way it'll provide a central location for everybody who runs into it to discuss potential workarounds.

Share this post


Link to post
Share on other sites
$ pwd
/home/kimballr/Downloads/foobar/sources/tools/gas/config
$ grep MAX_OP_LEN tc-msp430.c
#define MAX_OP_LEN 256
  char l1[MAX_OP_LEN], l2[MAX_OP_LEN];

I'm guessing that is what is killing me

 

-rick

Share this post


Link to post
Share on other sites

So yeah, I grabbed the source and changed that define to 4096 instead of 256. Then I  recompiled the gas program. After I replaced the 4.9.1 version of msp430-elf-as with this newly built one, I was able to successfully compile my original code that happens to create long template names. 

$ msp430-elf-nm blink.o
00000000 W _ZN6print_I17serial_eusci_a0_tILm9600ELm16000000E8GPIO_PINI9GPIO_PORTILi50ELZ6PAIN_HELZ7PAOUT_HELZ7PADIR_HELZ8PASEL0_HELZ8PASEL1_HELZ8PASELC_HELZ7PAREN_HELZ7PAIFG_HELZ7PAIES_HELZ6PAIE_HEELh1E14gpio_pincaps_tILb0ELb0ELb0ELb0ELb0ELb0EEE9GPIO_NULLILh0EEEE5writeEh

$ echo _ZN6print_I17serial_eusci_a0_tILm9600ELm16000000E8GPIO_PINI9GPIO_PORTILi50ELZ6PAIN_HELZ7PAOUT_HELZ7PADIR_HELZ8PASEL0_HELZ8PASEL1_HELZ8PASELC_HELZ7PAREN_HELZ7PAIFG_HELZ7PAIES_HELZ6PAIE_HEELh1E14gpio_pincaps_tILb0ELb0ELb0ELb0ELb0ELb0EEE9GPIO_NULLILh0EEEE5writeEh  | wc
      1       1     261
$ msp430-elf-c++filt -t _ZN6print_I17serial_eusci_a0_tILm9600ELm16000000E8GPIO_PINI9GPIO_PORTILi50ELZ6PAIN_HELZ7PAOUT_HELZ7PADIR_HELZ8PASEL0_HELZ8PASEL1_HELZ8PASELC_HELZ7PAREN_HELZ7PAIFG_HELZ7PAIES_HELZ6PAIE_HEELh1E14gpio_pincaps_tILb0ELb0ELb0ELb0ELb0ELb0EEE9GPIO_NULLILh0EEEE5writeEh
print_<serial_eusci_a0_t<9600ul, 16000000ul, GPIO_PIN<GPIO_PORT<50, PAIN_H, PAOUT_H, PADIR_H, PASEL0_H, PASEL1_H, PASELC_H, PAREN_H, PAIFG_H, PAIES_H, PAIE_H>, (unsigned char)1, gpio_pincaps_t<false, false, false, false, false, false> >, GPIO_NULL<(unsigned char)0> > >::write(unsigned char)
$

: ) and people wonder why I like open source stuff

 

-rick

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×