Sunday, February 15, 2015

MSP430 and Fedora 21 - The same but different

If you've tried doing any work with the GCC compiler officially packaged by the Fedora Project, you've probably run into issues when trying to link. The issue is correctly identified on that bug report, the strip step of building the RPM needs to be worked around. Unfortunately the maintainer of those packages hasn't stepped forward to push a fix.

I considered fixing the issue myself, but I'd recently discovered that TI and Red Hat have started work on their own supported version of the GNU toolchain for the MSP430. Instead of fixing the current packages (which are packaging source that is over 4 years old now), I packaged the new TI / Red Hat version. Sure, it was time consuming, but when you have a new yo-yo your brother got you for Christmas, the compile time just flies by.




Before pressing on, I should let you know you know that if you intend on using GDB for debugging your MSP430 projects, you'll be stuck installing both the toolchain and the XDS Emulation Software Package directly from TI so that you can copy the necessary files to use the XDS GDB Agent for the MSP430. The licensing does not allow me to package those particular files (if someone from TI would like to make a deal, feel free to contact me). Since you'd be doing a full install anyway, using my repo may not hold much appeal for you.

With that out of the way, let's go through what it takes to install my packages, and use the newer GCC version. First, enable my 'msp430-development-tools' Copr repo. Then install the toolchain and support files:

# yum install msp430-elf-gcc msp430-elf-binutils msp430-elf-gdb mspds msp430flasher msp430-gcc-support-files dos2unix

If you have the official Fedora packages installed, (particularly the msp430mcu package), you may have package conflicts when installing the above. Remove the offical Fedora MSP430 development packages then run the above command again.

With that installed, you're ready to compile for the MSP430, and flash binaries as well. Unfortunately the commands for both have changed. For your convenience, here is an updated Makefile for Project 0.1 which shows the changes (the prefix for the compiler binaries is now msp430-elf, and we flash using MSP430Flasher):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
#
# Makefile for msp430
#
# 'make' builds everything
# 'make clean' deletes everything except source files and Makefile
# 'make install' builds everything, and programs the MSP430 using MSPFLASHER
# You need to set TARGET, MCU and SOURCES for your project.
# TARGET is the name of the executable file to be produced
# $(TARGET).elf $(TARGET).hex and $(TARGET).txt nad $(TARGET).map are all generated.
# The TXT file is used for BSL loading, the ELF can be used for JTAG use
#
TARGET     = project0
MCU        = msp430f5529
# MSP430Flasher name
MSPFLASHER = MSP430Flasher
# List all the source files here
# eg if you have a source file foo.c then list it here
SOURCES = main.c delay.c
# Include are located in the Include directory
INCLUDES = -IInclude
# Add or subtract whatever MSPGCC flags you want. There are plenty more
#######################################################################################
CFLAGS   = -mmcu=$(MCU) -g -Os -Wall -Wunused $(INCLUDES)
ASFLAGS  = -mmcu=$(MCU) -x assembler-with-cpp -Wa,-gstabs
LDFLAGS  = -mmcu=$(MCU) -Wl,-Map=$(TARGET).map
########################################################################################
CC       = msp430-elf-gcc
LD       = msp430-elf-ld
AR       = msp430-elf-ar
AS       = msp430-elf-gcc
NM       = msp430-elf-nm
OBJCOPY  = msp430-elf-objcopy
RANLIB   = msp430-elf-ranlib
STRIP    = msp430-elf-strip
SIZE     = msp430-elf-size
READELF  = msp430-elf-readelf
MAKETXT  = srec_cat
CP       = cp -p
RM       = rm -f
MV       = mv
########################################################################################
# the file which will include dependencies
DEPEND = $(SOURCES:.c=.d)
# all the object files
OBJECTS = $(SOURCES:.c=.o)
all: $(TARGET).elf $(TARGET).hex $(TARGET).txt
$(TARGET).elf: $(OBJECTS)
 echo "Linking $@"
 $(CC) $(OBJECTS) $(LDFLAGS) $(LIBS) -o $@
 echo
 echo ">>>> Size of Firmware <<<<"
 $(SIZE) $(TARGET).elf
 echo
%.hex: %.elf
 $(OBJCOPY) -O ihex $< $@
%.txt: %.hex
 $(MAKETXT) -O $@ -TITXT $< -I
 unix2dos $(TARGET).txt
#  The above line is required for the DOS based TI BSL tool to be able to read the txt file generated from linux/unix systems.
%.o: %.c
 echo "Compiling $<"
 $(CC) -c $(CFLAGS) -o $@ $<
# rule for making assembler source listing, to see the code
%.lst: %.c
 $(CC) -c $(ASFLAGS) -Wa,-anlhd $< > $@
# include the dependencies unless we're going to clean, then forget about them.
ifneq ($(MAKECMDGOALS), clean)
-include $(DEPEND)
endif
# dependencies file
# includes also considered, since some of these are our own
# (otherwise use -MM instead of -M)
%.d: %.c
 echo "Generating dependencies $@ from $<"
 $(CC) -M ${CFLAGS} $< >$@
.SILENT:
.PHONY: clean
clean:
 -$(RM) $(OBJECTS)
 -$(RM) $(TARGET).*
 -$(RM) $(SOURCES:.c=.lst)
 -$(RM) $(DEPEND)
install: $(TARGET).txt
   $(MSPFLASHER) -n $(MCU) -w "$(TARGET).txt" -v -z [VCC]

From there, everything continues as normal, typing 'make' compiles, 'make install' will compile and write to the LaunchPad, running the program when the write is finished.

Debugging using GDB is a bit more involved. You will need the "Redhat GCC Linux installer incl. support files and debug stack and USB drivers" as well as the Linux version of the XDS Emulation Software Package. Install both using the '.run' files as instructed. The following instructions assume you do not want to leave those packages installed. So we copy the necessary files for the XDS GDB Agent. Make a folder to put the agent in, then, assuming you installed the packages to the default location, copy both '~/ti/gcc/bin/gdb_agent_console' and '~/ti/gcc/msp430.dat' to your newly created folder. You can now remove the above packages by running '~/ti/gcc/uninstall' and '~/ti/uninstallers/uninstall_ti_emupack_5.1.636.0'. Then delete the leftover 'ti' directory. If you are running 64 bit Fedora, you will also need a 32 bit install of the MSP Debug Stack, which I have packaged here.

You can now start the GDB agent by typing './gdb_agent_console msp430.dat'. Connect to the agent the same way we did in Project 0.2, but instead using 'msp430-elf-gdb' and changing the port number to 55000. From there, debugging is the same.

Extra credit: interrupts

If you run into compile errors in projects with interrupts, check this out.

Extra extra credit: easy debug bridge

Having to be in the folder you copied the XDS GDB Agent to is a real drag. I hacked together the below script, and symlinked it into my path, so I can launch the debug agent wherever I am:

1
2
3
4
#!/bin/bash
DIR="$(dirname "$(readlink -f "$0")")"

$DIR/gdb_agent_console $DIR/msp430.dat

33 comments:

  1. I'm getting /usr/lib64/gcc/msp430-elf/4.9.1/430/crtbegin.o uses MSP430 instructions but /usr/lib64/gcc/msp430-elf/4.9.1/crt0.o uses MSP430X errors using your coprs on fedora 22. Compiling for msp430f169.

    ReplyDelete
    Replies
    1. Thanks for finding that! I can recreate it here, let me look into it.

      Did you see the same in Fedora 21?

      Delete
    2. Should be fixed, just pushed updated packages to copr (msp430-elf-binutils-3.3.4-2, msp430-elf-gcc-3.3.4-2, msp430-elf-gdb-3.3.4-2). Thanks again for the report!

      Delete
    3. Thanks, that fixed it for me. I haven't tried it on Fedora 21. Went from working F20 msp430-gcc to F22 with your copr msp430-elf-gcc as msp430-gcc is unlikely to be fixed.

      Delete
  2. Thanks for the repos! I am using Fedora 22 x86_64. Any chance you can provide the Makefile as a download? I'm unsure if I added all the 'tabs' I needed after cutting and pasting above.

    I'm getting a warning about my interrupt: warning: argument of ‘interrupt’ attribute is not a string constant or number [-Wattributes]

    My ISR:

    __attribute__((interrupt(TIMER_A0_VECTOR)))

    void TIMER1_A0_ISR(void)
    {

    if(bitstream[byteindex] & (1<<(7-bitindex))) //Next bit 1?
    {

    drate = 0;
    tone(1250,1);

    Any suggestions?

    ReplyDelete
    Replies
    1. Glad the repos help someone!

      I made a snippet of the Makefile here: https://bitbucket.org/snippets/nielsenb/dREeB

      You need to match your vector name to the one specified in the header file for the micro you're compiling for, most likely TIMER1_A0_VECTOR

      See this thread for more details: http://forum.43oh.com/topic/5747-msp430-elf-gcc-errors-on-builtin-sr-function/

      Delete
    2. Quick update, for the sake of completeness I uploaded all of 'Project0.1' to a snippet:

      https://bitbucket.org/snippets/nielsenb/6Lrqx

      Delete
  3. Noob instructions, as used in Fedora 22 XFCE

    INSTALL TOOLCHAIN

    - open a Terminal window
    sudo dnf copr enable nielsenb/msp430-development-tools
    (enter your password)
    sudo dnf install msp430-elf-gcc msp430-elf-binutils msp430-elf-gdb mspds msp430flasher msp430-gcc-support-files dos2unix

    I am at a loss on how to use MSP430Flasher. So I use mspdebug

    sudo dnf install mspdebug

    USAGE

    assuming:
    - MSP430 Launchpad with MSP430g2553 (vanilla "out-of-the-box") connected to your USB port
    - a file with C code, mycode.c

    this instruction will compile mycode.c, and output outfile.o :

    msp430-elf-gcc -mmcu=msp430g2553 mycode.c -o outfile.o

    and this will upload the compiled code to the MCU:

    sudo mspdebug rf2500 "prog outfile.o"

    RANT

    Up to today the only way I was able to do my MSP430-fu on Fedora 22 was with
    the energia/hardware/tools/msp430/ folder extracted from a download of Energia,
    as per Aswin Venu's comment here https://bugzilla.redhat.com/show_bug.cgi?id=1175942
    Messy, huge, old.

    Usually with Fedora, I had been able to install my toolchain with a simple
    sudo yum install msp430-libc mspdebug
    even in the OLPC XO laptops, the famous $100 laptops of years ago.
    but in Fedora 22 that was useless, some missing files at compile time
    cannot find -lgcc
    cannot find -lcrt0

    Another, why why why WHY does the spelling/grammar for the code keep changing?
    my ex-Energia tools work fine with my old code. Brandon's msp430-elf-gcc balks
    at the interrupts and constants assignment. Trying code examples from the 'tubes
    is hit-and-miss, and it's embarrassing to share my code, knowing that it will mostly
    frustrate others. (I will look again at Brandon's comments on that kind of stuff)
    (this is not a new thing, but seems to be getting worse)

    one more, the TI documentation is thorough, highly detailed, thus essentially
    useless for the beginner, even more so if in Linux. That is, if you can find it,
    the thing is riddled with 404 responses when following blogs or even TI
    personnel posts. See http://sourceforge.net/p/mspgcc/mailman/message/34475889/
    I tried msp430-gcc-full-linux-installer-3.5.0.0.run with no
    apparent effect. (hopefully nothing broke, either)

    A last one: No simple examples of MSP430Flash from Linux command line, anywhere I tried.
    The only realistic solution, and uttermost silly, would be to run the .exe in Wine.
    And that thing that Linux installs msp430flash, but it needs capitals to run at all...
    Hopefully I'll figure it out, but as long as my mspdebug works, I'm mostly OK

    BOTTOM LINE

    I used to enthusiastically suggest the MSP430 to the noob. Now I'm not so sure

    Maybe Arduino truly is the only way for the beginner, and PIC for the true wizard,
    TI MSP430 maybe trying to get that later role through obscurity?... I don't know.
    Personally I dislike the bloated Arduino UI (and Energia, for the same reason,
    and the CCS TI compilers 10 times over). The lerning curve is SO steep, even for
    a Hello World, it's not even funny. Unless you use that Majority OS, which
    anyway marks you as a True Noob For Life. The Wise-r Noob is sort of left hanging.
    Sort of a contradiction as a strategy, for TI...

    msp430-gcc was something I was (and still am) quite happy for my needs,
    which are few. Some stepper motors, thermocouples, a bit of animatronics, IoT...
    I love it that with MSP430 I can have an IoT node at a BOM cost of $1.50
    They tell me I could get something like that with ATMEL, haven't tried.

    So, a big D-Beer hug to all, thank you Brandon for what you have put together,
    and good luck to anyone trying this path.

    ReplyDelete
  4. edit: says MSP430Flash, should say MSP430Flasher

    ReplyDelete
  5. Brandon,

    I need help to get around the interrupt grammar.

    $ msp430-elf-gcc -mmcu=msp430g2553 temp04.c -o outfile.o

    temp04.c:61:13: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’
    __interrupt void USCI0RX_ISR(void){
    ^
    The code works fine with older msp430-gcc. I am afraid that what I had been using is/was "legal", and I cannot find any reference to the "new" ways of doing things, so I am a it stuck with this particular situation when trying to use msp430-elf-gcc.

    All examples I find in the 'tubes for vector=USCIAB0RX_VECTOR have this same exact construct that I am using.

    Here is my whole code, with my apologies, a spaghetti of odds and bits picked up here and there, mostly Benn Thomsen's (but it works! I just have to compile it with a pre 2014 msp430-gcc)

    /* Example code demonstrating the use of the hardware UART on the MSP430G2553 to receive
    * data back to a host computer over the USB connection on the MSP430
    * launchpad.
    *
    * Original good code by Benn Thomsen, horribly mangled later by ATXinventor
    * compiles with pre-2014 msp430-gcc on Fedora 22, but fails with msp430-elf-gcc
    *
    * for display of Pin 3 potentiometer data on screen, use
    *
    * sudo minicom -D /dev/ttyACM0 -b 9600 -8
    *
    */

    #include "msp430.h"
    #include "msp430g2553.h"
    #include "string.h"
    #include "stdio.h"
    void UARTSendArray(unsigned char *TxArray);

    //static volatile char data;
    static unsigned char data;
    int mytemp=0;
    char str[15];
    #define BUTTON BIT3
    void ADC_init(void);
    void main(void)

    {
    WDTCTL = WDTPW + WDTHOLD; // Stop WDT
    ADC_init();
    P1DIR |= BIT0 + BIT6; // Set the LEDs on P1.0, P1.6 as outputs
    P1OUT = BIT0; // Set P1.0 -> turn on red LED at startup
    BCSCTL1 = CALBC1_1MHZ; // Set DCO to 1MHz
    DCOCTL = CALDCO_1MHZ; // Set DCO to 1MHz
    P1IE |= BUTTON; // P1.3 interrupt enabled
    P1IFG &= ~BUTTON; // P1.3 IFG cleared

    /* Configure hardware UART */
    P1SEL = BIT1 + BIT2 ; // P1.1 = RXD, P1.2=TXD
    P1SEL2 = BIT1 + BIT2 ; // P1.1 = RXD, P1.2=TXD
    UCA0CTL1 |= UCSSEL_2; // Use SMCLK
    UCA0BR0 = 104; // Set baud rate to 9600 with 1MHz clock (Data Sheet 15.3.13)
    UCA0BR1 = 0; // Set baud rate to 9600 with 1MHz clock
    UCA0MCTL = UCBRS0; // Modulation UCBRSx = 1
    UCA0CTL1 &= ~UCSWRST; // Initialize USCI state machine
    IE2 |= UCA0RXIE; // Enable USCI_A0 RX interrupt
    __bis_SR_register(LPM0_bits + GIE); // Enter LPM0, interrupts enabled
    }

    // ========================================================
    // ADC configured to read temperature
    void ADC_init(void) {
    ADC10CTL0 = SREF_1 + REFON + ADC10ON + ADC10SHT_3;
    ADC10CTL1 = INCH_3 + ADC10DIV_3;
    }

    // Echo back RXed character, confirm TX buffer is ready first
    #pragma vector=USCIAB0RX_VECTOR
    __interrupt void USCI0RX_ISR(void){
    mytemp = getTemperatureCelsius();
    sprintf(str, "%d", mytemp);
    strcat(str," . ");
    UARTSendArray(str);
    UARTSendArray("\n\r");
    }

    void UARTSendArray(unsigned char *TxArray){
    // Send number of bytes Specified in ArrayLength in the array at using the hardware UART 0
    // Example usage: UARTSendArray("Hello", 5);
    // int data[2]={1023, 235};
    // UARTSendArray(data, 4); // Note because the UART transmits bytes it is necessary to send two bytes for each integer hence the data length is twice the array length
    int le = strlen(TxArray);
    while(le--){ // Loop until StringLength == 0 and post decrement
    while(!(IFG2 & UCA0TXIFG)); // Wait for TX buffer to be ready for new data
    UCA0TXBUF = *TxArray; //Write the character at the location specified py the pointer
    TxArray++; //Increment the TxString pointer to point to next character
    }
    }

    int getTemperatureCelsius()
    {
    int tt = 200;
    long ttt = 0;
    while (tt--) {
    int t = 0;
    __delay_cycles(2000);
    ADC10CTL0 |= ENC + ADC10SC;
    while (ADC10CTL1 & BUSY);
    t = ADC10MEM;
    ADC10CTL0 &=~ ENC;
    ttt=ttt-((t * 2706900L - 181998250L) >> 16);
    }return(int) (ttt / 5000+58);}

    ReplyDelete
  6. Using @pabigot suggestion, I get past /that/ error
    http://sourceforge.net/p/mspgcc/mailman/message/25346984/

    // this code compiles with old msp430-gcc, but not with msp430-elf-gcc
    // #pragma vector=USCIAB0RX_VECTOR
    // __interrupt void USCI0RX_ISR(void){

    // this other seems to compile a bit better with msp430-elf-gcc,
    //but gives a ROM overflow message: msp430-elf/bin/ld: region `ROM' overflowed by
    // Either compiles fine with msp430-gcc

    __attribute__((interrupt(USCIAB0RX_VECTOR)))
    void USCI0RX_ISR(void){

    quote from another pabigot post "Some of it is that msp430-elf doesn't generate quite as compact code as mspgcc did."

    so I tested that with a Hello World of mine, that does compile under either.

    compiled with msp430-elf-gcc: 13.2 K object code
    compiled with msp430-gcc: 7.4 K object code

    end of story. Not your fault, Brandon, but what's the point to use a compiler that makes object code files almost 2 times larger?

    At least I learned a few tricks here and there.
    (yeah, there are supposed to be advanced hacks to put things in Higher Memory, and additional included files, but then that again defeats the purpose of Simple, and Compatible Code)

    for the duration I'll stick to old msp430, as per Aswin Venu's comment in https://bugzilla.redhat.com/show_bug.cgi?id=1175942

    That works better (for me) than the up-to-date-r alternative

    Thank you all!

    ReplyDelete
    Replies
    1. I tend to agree with all your above comments. TI / Red Hat are working on making the 'new' stack better, but there is a ways to go. They still don't seem to understand that not everyone wants to use their binary installers for the toolchain, and would instead prefer RPM. They are 90% of the way there, but I've yet to be able to get them to license the code necessary to actually use their GDB implementation in such a way I can package it for Fedora. And even if they do, it still won't change the syntax changes that keep tripping people up.

      In TI's defense, they are extremely responsive on their official forums: http://e2e.ti.com/support/development_tools/compiler/

      I'm glad you got your code to compile, I'm sorry it wound up not fitting in the end. Did you try compiling with '-Os' (optimize for size)? Not sure it'll help, but I can't say I've noticed code being significantly larger with msp430-elf-gcc, but I also don't pay that close of attention until something doesn't fit.

      I haven't had any problems with MSP430Flasher, but I agree with you that the name is annoying since Linux binaries rarely have capital letters. That being said, it does require a bit more digging in the help to actually get it to do what you want.

      I also highly recommend you start using Makefiles like the one in my Project 0.1 snippet: https://bitbucket.org/snippets/nielsenb/6Lrqx

      Usually once you've got a Makefile that works for your project, you just have to occasionally modify the sources line. It makes it easier for other people to use your code as well, since they don't have to remember how to build it.

      Sorry again! Thanks for the comments!

      Delete
  7. Hi I'm trying to compile on Fedora25 and am getting:

    /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld: error: /usr/msp430-elf/lib/libc.a(lib_a-atoi.o) uses MSP430X instructions but /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/lib/430/crt0.o uses MSP430

    Thanks

    James

    ReplyDelete
    Replies
    1. Sorry about that! I had half of an update pushed that I thought I backed out of.

      You'll probably have to uninstall then install the MSP430 stuff again:

      dnf remove msp430-elf-gcc msp430-elf-binutils msp430-elf-gdb mspds msp430flasher msp430-gcc-support-files

      dnf install msp430-elf-gcc msp430-elf-binutils msp430-elf-gdb mspds msp430flasher msp430-gcc-support-files

      Delete
    2. I re-installed as you suggested, but it still has the same error.

      Thanks

      James

      Delete
    3. Interesting. What MCU are you compiling for? I can't reproduce the issue here anymore.

      Delete
    4. Its a msp430F169. Here's a longer list, the 4096 byte limit won't let be post the full list.

      /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld: error: /usr/msp430-elf/lib/libc.a(lib_a-atoi.o) uses MSP430X instructions but /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/lib/430/crt0.o uses MSP430
      /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld: failed to merge target specific data of file /usr/msp430-elf/lib/libc.a(lib_a-atoi.o)
      /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld: error: /usr/msp430-elf/lib/libc.a(lib_a-memcpy.o) uses MSP430X instructions but /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/lib/430/crt0.o uses MSP430
      /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld: failed to merge target specific data of file /usr/msp430-elf/lib/libc.a(lib_a-memcpy.o)
      /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld: error: /usr/msp430-elf/lib/libc.a(lib_a-sprintf.o) uses MSP430X instructions but /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/lib/430/crt0.o uses MSP430
      /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld: failed to merge target specific data of file /usr/msp430-elf/lib/libc.a(lib_a-sprintf.o)
      /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld: error: /usr/msp430-elf/lib/libc.a(lib_a-strcat.o) uses MSP430X instructions but /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/lib/430/crt0.o uses MSP430
      /usr/lib64/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld: failed to merge target specific data of file /usr/msp430-elf/lib/libc.a(lib_a-strcat.o)

      Delete
    5. That's really strange, I can compile for that target fine. Do you have a Makefile or something I can see to try to reproduce the issue?

      You can file a bug Bitbucket if you want to post bigger messages: https://bitbucket.org/nielsenb/mspgcc-fedora

      So sorry this isn't working for you!

      Delete
    6. Ok, so your hint at looking at my make file was the key. By commenting out
      LIBS = -L/usr/msp430-elf/lib
      fixed it. Not sure why.

      Thanks

      Delete
  8. This comment has been removed by the author.

    ReplyDelete
  9. Seems an update barfed something. Now cannot compile:
    fatal error: msp430.h: No such file or directory
    #include

    Has there been any recent updates?

    ReplyDelete
    Replies
    1. Yes, I recently updated everything to the new TI / Somnium upstream, unfortunately they changed version numbers around which may have broken some things. Sorry about that!

      Try an uninstall, install, and let me know if that fixes it. If it doesn't, I can try to look into it more:

      dnf remove msp430-elf-gcc msp430-elf-binutils msp430-elf-gdb mspds msp430flasher msp430-gcc-support-files

      dnf install msp430-elf-gcc msp430-elf-binutils msp430-elf-gdb mspds msp430flasher msp430-gcc-support-files

      Delete
    2. Okafter a reinstal. A new error:

      hardware.c:45:1: internal compiler error: in msp430_attr, at config/msp430/msp430.c:1835
      {
      ^
      Please submit a full bug report,
      with preprocessed source if appropriate.
      See for instructions.

      Delete
    3. It seems that interrupt declarations have changed from __interrupt__ to interrupt. Plus a few other gcc4 to gcc5 changes. Fixing the inturrupt declarations have fixed the error.

      Thanks

      James

      Delete
  10. The latest update fails to compile files with:

    hardware.c:1:0: warning: devices.csv not found on any include paths.
    Please obtain the latest version of the msp430-gcc-support-files archive from:
    "http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/index_FDS.html"
    and place the full path to the "include" directory containing devices.csv on an include path specified with -I
    Defaulting to the hard-coded device data...
    #include

    hardware.c:1:20: fatal error: msp430.h: No such file or directory
    #include

    Does the msp430-gcc-support-files need to be updated as per the output?

    James

    ReplyDelete
    Replies
    1. The (unfortunately likely to be final update) of the Somnium version now nags if you don't use the 'dynamic' device definition files. To use them, change your include path, if using a Makefile, it'll look something like this:

      INCLUDES = -I/usr/lib64/gcc/msp430-elf/6.4.0/include

      Or, on 32 bit platforms:

      INCLUDES = -I/usr/lib/gcc/msp430-elf/6.4.0/include

      That'll stop the nagging. If you don't change the include path, the compiler should act the same as it did before, but with the nagging.

      As for the missing msp430.h, I don't see that issue here. You could try uninstalling and reinstalling:

      dnf remove msp430-elf-gcc msp430-elf-binutils msp430-elf-gdb mspds msp430flasher msp430-gcc-support-files

      dnf install msp430-elf-gcc msp430-elf-binutils msp430-elf-gdb mspds msp430flasher msp430-gcc-support-files

      Delete
    2. Before dnf remove ..., then dnf install

      If I include /usr/lib64/gcc/msp430-elf/6.2.1/include it compiles but nags about the definition files.
      If I include /usr/lib64/gcc/msp430-elf/6.4.0/include gives the above error and fails.

      After I reinstall via dnf

      If I include /usr/lib64/gcc/msp430-elf/6.4.0/include it compiles put fails to link:
      /usr/lib64/gcc/msp430-elf/6.4.0/../../../../msp430-elf/bin/ld: error: hardware.o uses MSP430 instructions but /usr/lib64/gcc/msp430-elf/6.4.0/../../../../msp430-elf/lib/crt0.o uses MSP430X

      Progress of sorts.



      Delete
    3. If I include /usr/msp430-elf/include/ it compiles and links but complains.

      James

      Delete
    4. The dnf reinstall removed /usr/lib64/gcc/msp430-elf/6.2.1/include

      Delete
    5. /usr/lib64/gcc/msp430-elf/6.2.1/include should be gone, the latest release is based on GCC 6.4.0

      As for your compilation issue, I get to claim not my fault. Either SOMNIUM or TI messed up the definition for the msp430f169 (and likely others) in the devices.csv file. It's listed as CPU_TYPE=0 (msp430), it should be CPU_TYPE=1 (msp430x).

      For now, I recommend just dealing with the nagging assuming that's not generating broken executables. When I get a chance, I'll try to fix the broken definitions in the devices.csv file.

      Delete
    6. Actually, the compiler is right; it should be compiling for an msp430, not msp430x. It's the linker that's confused for some reason.

      Adding -mcpu=430 to your LDFLAGS (or whatever you pass into the link step) should fix your issue.

      Delete