MSP430 multiple serious GCC problems

Hi,

We (I and some colleages)  have also found some problems with GCC for MSP430X, and particularly for large memory model, but we have to keep in mind that it is still considered to be experimental and that we have been warned about this. 

Regarding your problems with flash allocation, it is true, GCC seems to have some problem with the Flash Memory gap in the 430X architecture (i. e. the space reserved for the interrupt vectors).  If you want to place functions beyond the first 64K of flash, you have to do it MANUALY, by defining a new section in the linker file (add the code bellow to the .ld file):

.far_rom :
{
. = ALIGN(2);
PROVIDE (_start = .);
KEEP (*(SORT(.crt_*)))
*(.lowtext .text .stub .text.* .gnu.linkonce.t.* .text:*)
KEEP (*(.text.*personality*))
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
*(.interp .hash .dynsym .dynstr .gnu.version*)
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
. = ALIGN(2);
KEEP (*(.init))
KEEP (*(.fini))
KEEP (*(.tm_clone_table))
} > FAR_ROM

And for those  functions you want to send to the far rom region, you have to add  "__attribute__ ((section(".far_rom"))) " to the function header.

Note that for this to work you have to use the large memory model by adding the "-mlarge"  flag in the "miscellaneous" compiler options of your project.

Even more critical than this, we have found quite an important bug in MSP430GCC for the large memory model. We have found that apparently, when in this mode, gcc gets confused by the PC+SR compact stacking in the 430X interrupts and does not calculate properly the stack frame for ISR, thus resulting in intrinsics like __bic_SR_register_on_exit (necessary to exit low power) catastrophically modifying the stacked PC instead of the stacked SR. A workarround for this is to "tweak" the stack  pointer so it matches the frame miscalculated by GCC, and then undo the tweak. This can be done with the inline assembler:

#ifdef __MSP430X_LARGE__
asm volatile ( "sub.w #2,sp" ); //workarround for MSP430X LARGE MEMORY bug of CCSv6's GCC v4.8.0
#endif
__bic_SR_register_on_exit( SCG1 + SCG0 + OSCOFF + CPUOFF );
#ifdef __MSP430X_LARGE__
asm volatile ( "add.w #2,sp" ); //workarround for MSP430X LARGE MEMORY bug of CCSv6's GCC v4.8.0
#endif

As commented before, be aware that msp430x large memory model in GCC is still experimental, and also, as many other free open source efforts, it is (understandably) quite poorly documented, at present. Thus I think its use is highly unadvised in critical projects for now. Small memory model seems to be much more stable and reliable (and thus more suitable for "real work" as you put it), but of course it limits the code size.  

Regards,

Jose

Thanks Jose, that is incredibly helpful. A couple follow-on questions:

Where did you find documentation for -mlarge? I was unable to find this. Also, does -mlarge specify large model for code only, or code and data? The part we are using has only 16kb of RAM.

Any idea about the mathlib multiple definitions? Or any documentation for hardware-multiplier options (the part we use has 32x32 bit multiplier).

Thanks again!
Best Regards, Dave

Hi Dave,

I don't recall just now if I heavily googled it (I have this between my bookmarks) or if I found it by invoking gcc from the command line (go to c:\ti\ccsv6\tools\compiler\gcc_msp430_4.8.371\bin and execute "msp430-elf-gcc.exe --target-help"). For what I have seen so far, I think  that -mlarge specify large model both for code and data, and that gcc does not support a "medium" model like other compilers (at least the 4.8.0 version included with CCSv6), but these things are quickly changing and I have found some posts on other forums suggesting there may be additional flags in different versions of the compiler. 

As for the hardware multiplier, this I had not tested so much, because I do not usually use math intensive code. Apparently if you use the -mmcu flag to pass the compiler your MCU variant (as you have), it will use its multiplier model by defaults. If I do this in my project, too (as you have done in yours) I get the same errors than you. Surprisingly the hardware multiplier specification flag (suposedly "-mmpy") in CCS compiler runtime options seems to be rejected by gcc, but instead, both in the command line and in the document linked above, it appears a "-mhwmult" option that could also be passed as a miscellaneous option to the compiler. If I pass -mhwmult=16bit (or if I pass a generic msp430x as -mmcu option and no hwmultiplier flag, which is what I have been using so far till now), I get rid of the errors. If I use a generic msp430x mcu and -mhwmult=32bit, again the same errors, so it seems to be related with the 32bits multipler configuration. Why on earth this happens, I do not know, may be it is related with how the libgcc runtime library has been compiled? Updated, see below

Regards,

Jose

Update: Sorry, in this last hurry test I was modifying compile options of a single folder, instead of the whole project. If you select -mmpu=msp430f5437A for the whole project (and be careful to not overload that configuration for any folder), it compiles OK and apparently it uses the correct multiplier for the MPU you are using.  My mistake, sorry.

In any case, -mhwmult (and not -mmpy) can overload the hardware multiplier configuration. So:

either "-mmpu=msp430f5437a" or "-mmpu=msp430x -mhwmult=f5series" compiles and should use the hardware multiplier.

Beware, check if you ar using the same options for all source folders in the project!

Regards,

Jose

Thanks Jose. I had not found the GNU.org MSP430 options, only the outdated documents on SourceForge.
To try summarize:

BUG: compiler fails to report its option help, as mentioned above:
c:\ti\ccsv6\tools\compiler\gcc_msp430_4.8.371\bin\msp430-elf-gcc.exe --target-help
returns:
gcc: error: CreateProcess: No such file or directory

BUG: Something is seriously broken with the multiply library selection scheme, resulting in the multiple definitions we have both seen preventing linking. In my project all components (no exceptions!) were compiled with -mmpu=msp430f5437a (and no -mmpy or -hwmult option), so there should have been no problem.

BUG: CCS6 prompts for -mmpy option with no dropdowns, but in any case that option does not exist in the compiler.

NO DOCUMENTATION: No compiler documentation has been provided, and the compiler options do not match what is documented in GNU area.

BUG: Incorrect code is generated for __bic_SR_register_on_exit - I'm suspicious this is not specific to large model or MSP430x, as two words are used for ISR context save on stack (SR+PC) in all cases.

FEATURE PROBLEM: The size of generated code plus library is much larger than other compilers. My project easily fits in 40kb using "large" model and no optimization with Rowley compiler, but building with GCC small model overflows low memory.

BUG: CCS6 does not properly show total memory used/available (discussed in an earlier post).

BUG: Large model code is "experimental" ???

FEATURE PROBLEM: No "medium" model - lots of MSP430 variants have small RAM in first 64kb but lots of flash (as in MSP430F437 we're using for this project). Lack of this feature will hurt code size.

Whoops! TI's GCC for MSP430 is not even close to ready for use in real projects!

Thanks again Jose for your efforts,
Best Regards, Dave

Hi,

Well, I agree with you more or less, but...

"--target-help" does work for me. 

If I do not meddle too much with hardware multiplier options, it seems to compile OK. Of course, as I said, I am not using much math operations (nor math libs) in my projects.

The problem we have found with  __bic_SR_register_on_exit is only for the large model. For this model the compiler miscalcutales the size of the stacked registers, and seems to assume that PC+SR size is 6 bytes, when in an ISR the size is still 4 bytes thanks to the compact stacking of the MSP430X. This results in __bic_SR_register_on_exit  modifying the lower bits of the stacked PC instead of the stacked SR. In the normal "small" mode, the compiler correctly calculates the size of the stacked PC+SR and so __bic_SR_register_on_exit  modifies the bits it is suposed to (we have tested and this works fine in small mode).

I do not think they claim it is ready for use in "real projects" (I understand you mean professional/comercial projects).  I think it is provided for now as an additional feature. I work in education, and for me "Free" is a very important feature (with free software tools and cheap development boards like the launchpad, students are allowed to do some practical homework). They have really much things to improve yet, but I positively think they are on the right track, and I appreciate their effort. I hope they will be improving the tool (instead of dropping it) and that it becomes more suitable for real/professional projects in a future. For now, as you said, its adoption is a bit risky.

Best Regards,

Jose

Agreed Jose - Really glad TI are trying to get onstream with GCC, and hope that this can be made into the stable product we have seen with GCC we use on many other platforms. This is pretty rough for a "Beta" though!

Strange that --target-help works for you but not me. I installed this around a week ago (Win7 32-bit); here's the full info though the GCC copyright notice shows March 2013:

c:\TI_CCS\ccsv6\tools\compiler\gcc_msp430_4.8.371\msp430-elf\bin>gcc --target-help
gcc: error: CreateProcess: No such file or directory

c:\TI_CCS\ccsv6\tools\compiler\gcc_msp430_4.8.371\msp430-elf\bin>gcc --version
gcc (GCC) 4.8.0 20130315 (experimental (msp430-130423-371)) (Red Hat/devo) [trunk revision 196673]
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Thanks again, good luck with the students!

Best Regards, Dave

Hi again, Dave,

I installed it about a month ago, but I think I have the same version than you. I am running an executable called "msp430-elf-gcc.exe" in "C:\ti\ccsv6\tools\compiler\gcc_msp430_4.8.371\bin", instead you are running the executable "gcc.exe" in "C:\ti\ccsv6\tools\compiler\gcc_msp430_4.8.371\msp430-elf\bin". If I run the one you are running, I get the same than you, no target help. If I run the msp430-elf-gcc.exe, I do get the target help:

C:\ti\ccsv6\tools\compiler\gcc_msp430_4.8.371\bin>msp430-elf-gcc.exe --target-help

The following options are target specific:
-masm-hex Force assembly output to always use hex constants
-mcpu= Specify the ISA to build for: msp430, mdsp430x,
msp430xv2
-mhwmult= Specify the type of hardware multiply to support
-minrt Use a minimum runtime (no static initializers or
ctors) for memory-constrained devices.
-mlarge Select large model - 20-bit addresses/pointers
-mmcu= Specify the MCU to build for.
-mrelax Optimize opcode sizes at link time
-msim Use simulator runtime
-msmall Select small model - 16-bit addresses/pointers
(default)

Assembler options
=================

Use "-Wa,OPTION" to pass "OPTION" to the assembler.

MSP430 options:
-mmcu=<msp430-name> - select microcontroller type
-mcpu={430|430x|430xv2} - select microcontroller architecture
-mQ - enable relaxation at assembly time. DANGEROUS!
-mP - enable polymorph instructions
-ml - enable large code model
-mN - do not insert NOPs after changing interrupts (default)
-mn - insert a NOP after changing interrupts
-mY - do not warn about missing NOPs after changing interrupts
-my - warn about missing NOPs after changing interrupts (default)
-md - Force copying of data from ROM to RAM at startup

Linker options
==============

Use "-Wl,OPTION" to pass "OPTION" to the linker.

no emulation specific options.

Curiously both files have the same size and date, and prompts the same when run with the -v flag (may be its the exec name, argv[0], which allows target-help to be properly displayed?).

C:\ti\ccsv6\tools\compiler\gcc_msp430_4.8.371\bin>msp430-elf-gcc.exe -v
Using built-in specs.
COLLECT_GCC=msp430-elf-gcc.exe
COLLECT_LTO_WRAPPER=c:/ti/ccsv6/tools/compiler/gcc_msp430_4.8.371/bin/../libexec/gcc/msp430-elf/4.8.0/lto-wrapper.exe
Target: msp430-elf
Configured with: /opt/redhat/msp430-130423-371/sources/tools/configure --host=i6
86-pc-mingw32 --build=i686-redhat-linux --target=msp430-elf --prefix=/opt/redhat
/msp430-130423-371/i686-pc-mingw32 --enable-languages=c,c++ --disable-itcl --disable-tk --disable-tcl --disable-libgui --disable-gdbtk
Thread model: single
gcc version 4.8.0 20130315 (experimental (msp430-130423-371)) (Red Hat/devo) [trunk revision 196673] (GCC)

I agree with you that, at least for MSP430X, it is more close to an alpha than to a beta release. I hopefully expect it will improve.

Regards, and thanks for your comments

Jose

Hi,

It is time to try MSP-GCC again. The newer 4.9.1 version looks promising.

Without an excessive and proper testing this version seems usable. I work on a dongle project which uses USB, UART, RTC, TIMER and a lot of FLASH with special code sections in linker command file, onboard programming, etc.

Not to mention the effort to migrate the project from Texas CL430 compiler to MSP-GCC was horrible, mostly because of the interrupt definitions, 20 bit pointer conversions and code section definitions. But all of them can be solved.

Now the project compiles and runs with both compilers. No effective problem were identified.

There are problems with MSP-GCC command line switches and documentation. But Google helps :-)

The code sizes are slightly greater with MSP-GCC.

It looks like a stable beta release, I think this is the right way.

Best whishes,
Tamas

Hi,

Thanks for the news.

Its true, I have been testing the large memory model of the latest (production) version and some of the bugs mentioned above seem to be fixed. The most critical one for me was the problem with the low power exit in large memory model, and now the stack frame seems to be properly calculated for ISR in large memory model and thus _bis_SR_register_on_exit actually modifies the stacked SR and works fine.

However, I still have some issues:

 Release notes now mention code split between low and far ROM is done automatically, but:

-> A) linker scripts provided with CCSv6 (and the ones downloadable from the TI GCC page) user only low rom

-> B) If I customize the script I can manually place code in low and far ROM, but no automatic splitting of code between the two memory regions so far (and I have not been able to figure out how to enable this). I will post a question in the forum specifically for this.