MSP430 Tools on Linux

mspgcc for CLI toolchain, mspdebug (http://homepages.xnet.co.nz/~dlbeer/) for code download/debugging. I haven't yet got to the point where I have a GUI working with the above. I haven't really looked at Eclipse so far, and Code::Blocks for Linux doesn't have support out-of-the-box for mspgcc (even though it does in the Windows version). Still a WIP. 

Very interesting, however seems is working only with newer version of kernel.

I'm trying with Ubuntu 8.04 (kernel 2.6.24-26 and 2.6.26-27) without success.
It seems there are problems with the USB dongle and this kernel version. What kernel was in use in the video ?
Or alternatively, what distribution was ?

I also tried with VirtualBox but I have the same problem.
The USB dongle is seen by the system but is not working, probably because "below" there is still the faulty USB management.

Great tip though !

There are issues with older kernels with regards to the ti_usb3410_5052 drivers and the USB FETs. You could try to recompile those drivers by hand from an updated source, but it might be easier to update Ubuntu at least to 9.04. I use 9.10 now and it works fine. 10.04 should be fine too.

I'm using ubuntu 9.10 with no luck:

usb 5-1: new full speed USB device using uhci_hcd and address 2
usb 5-1: configuration #1 chosen from 1 choice
usbcore: registered new interface driver hiddev
/build/buildd/linux-2.6.31/drivers/hid/usbhid/hid-core.c: usb_submit_urb(ctrl) failed
generic-usb 0003:0451:F432.0001: timeout initializing reports
generic-usb 0003:0451:F432.0001: hiddev96,hidraw0: USB HID v1.01 Device [Texas Instruments Texas Instruments MSP-FET430UIF] on usb-0000:00:10.3-1/input1
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
cdc_acm 5-1:1.0: This device cannot do calls on its own. It is not a modem.
cdc_acm 5-1:1.0: No union descriptor, testing for castrated device
cdc_acm 5-1:1.0: ttyACM0: USB ACM device
usbcore: registered new interface driver cdc_acm
cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
(ttyACM0) opening serial device...
(ttyACM0): probe requested by plugin 'Generic'
(ttyACM0) closing serial device...

$>mspdebug  uif -d /dev/ttyACM0
MSPDebug version 0.9 - debugging tool for MSP430 MCUs
Copyright (C) 2009, 2010 Daniel Beer <daniel@tortek.co.nz>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Trying to open UIF on /dev/ttyACM0...
Initializing FET...
uif: read error: Connection timed out
fet: open failed

Do you have another program running (in the background) that ties serial ports whenever they come available. Brltty (a braille reader) is notorious for doing this. Uninstall it unless you are dependent on braille TTYs.

As far as I now I'm not running any process more than those that come by default in ubuntu.

I am running Ubuntu 9.04 with kernel 2.6.28-19 and mspdebug is working great with the rf2500 driver and a launchpad,  the only thing i can think of trying is a different driver.

$ sudo mspdebug rf2500

MSPDebug version 0.9 - debugging tool for MSP430 MCUs
Copyright (C) 2009, 2010 Daniel Beer <daniel@tortek.co.nz>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Trying to open interface 1 on 010
Initializing FET...
FET protocol version is 30066536
Configured for Spy-Bi-Wire
Set Vcc: 3000 mV
Device ID: 0xf201
Device: MSP430F2013
Code memory starts at 0xf800

...

and you may want to upgrade your msp tool chain to mspgcc4 found  here http://mspgcc4.sourceforge.net/ 

I think it may be better maintained then the original based on gcc3

A warm welcome to Adrian (and also the rest of the community),

well, Linux is the first step to the right direction (in getting rid of this *!ß-.* Redmond stuff), but remember: There are guys (like me) out here who rely on UNIX (MAC OSx)! So, pls do not forget them!

Rgds
aBUGSworstnightmare

aBUGSworstnightmare said:

A warm welcome to Adrian (and also the rest of the community),

Anyway, well, support for MAC would be a nice thing, but since Apple has finally decided to provide support for Windoze on their machines, even virtual ones, there's no need to write dedicated Mac versions of everything.
The user base doesn't justify the development effort. MAC users are mostly that: users. Not developers. So while Linux support is an important thing, based on the fact that the Linux world is growing fast and most of the Linux users are the adventurous kind (and therefore a high percentage of potential or real MSP developers is found there), there is no significant number of potential MSP developers in the MAC world (maybe you're the only one?).

Hey guys...

I have followed a couple of tutorials and finally managed to get eclipse to work with mspgcc and mspgdb in order to debug the devices and everything. However, my problem is that I cannot compile the code for some reason. I am using the IAR LED example, and my problem seems to be with the included file:  #include <msp430.h> 

When I try to compile the project (be it in eclipse or only with mspgcc through the command line), I get an error message. Attached you can find the source code, but the only included file is msp430.h 

Now this is the error message I get when I try compile it:

In file included from msp430x2xx_fet_1.c:21:

/home/alvaro/workspace/inc/msp430.h:12: warning: ignoring #pragma system_include 

In file included from msp430x2xx_fet_1.c:21:

/home/alvaro/workspace/inc/msp430.h:674:2: error: #error "Failed to match a default include file"

Additionally, I tried to remove this file and include only the header file for my MSP430 (#include <msp430f2013.h>). These files are the ones taken from the IAR Installation Folder, so I don't know if they are compatible with mspgcc (but my guess is that they're not because of the error message i got when including this file only).  The following is the error at compile time:

In file included from msp430x2xx_fet_1.c:21:

/home/alvaro/workspace/inc/msp430f2013.h:28:2: error: #error msp430f2013.h file for use with ICC430/A430 only

Has anyone else experienced something like this? Do we need different header files for mspgcc?

IAR and CCS use different mechanisms for declaring interrupt functions, inline assembly (which is used for declaring the registers or dealing with LPMs, as this is outside the C language capabilities) and so on.

So yes, you
- need different MSP headers (which should come with MSPGCC), do NOT put the includes for IAR/CCS in your include path, none of them.
- you need to specify teh processor type in the makefile/compiler call (-mmcu=msp430f2013) so the compiler can properly support known errata or hardware multiplier or such and the linker knows what is where) and
- you need to change some things in the source code, such as the definitions for interrupt functions (basically everything that is labeled '#pragma', which is a 100% compiler specific preprocessor directive)

The proper includefile to use is normally 'io.h', which will select the proper mspxxx.h file based on the makefile processor settings. If you use a processor setting for a compatible processor (same segment locations and mostly common hardware) but need to load the header definitions for a different one which is not (yet) supported by the compiler, you can directly include the appropriate mspxxx.h file or write your own. On MSPGCC, the header files are modular, so the mspxxx.h file just includes the required header files for the existing hardware (besides defining some really processor-specific things).

Alvaro Aguilar said:

#error msp430f2013.h file for use with ICC430/A430 only

Alvaro Aguilar said:

warning: ignoring #pragma system_include 

Alvaro Aguilar said:

#error "Failed to match a default include file"

You can identify instructed errors and warning (those thrown with an #error/#warning directive while running the preprocessor) by the preceding #error or #warning right before the error text ("error: #error text" instead of "error: text"). Those usually refer to a global configuration problem (an important prerequisite is not met) and do not point out an actual C language compiler error.

Hey thanks a lot for the information! It turns out I was including the files from the IAR Embedded Workbench rather than the ones from mspgcc. After removing the IAR files from the include path, I was able to compile the file with no problem. I am still having some trouble with the debug process and running the program on my actual device, but other than that I already have Eclipse set up to compile with msp430-gcc and the debug tools. I am actually writing up a little tutorial right now with all the steps I took in order to get it to work, and I was wondering if you guys would be interested in something like that? Or maybe I should just leave it aside? 

Anyway, it's basically just a compilation of other documents I found helpful during my endeavor. 

Once again, thanks for the help.

Alvaro Aguilar said:

I am actually writing up a little tutorial

Alvaro Aguilar said:

I am still having some trouble with the debug process and running the program on my actual device

If you have problems with the process of uploading the code to the MSP, then this is a difficult field. I also have problems from time to time when flashing MSPs even with the old (and usually painless) serial programmer. Sometimes it just doesn't find the target and after some power-cycles or dis- and reconnecting it suddenly works again.

Which programmer do you use? Which version of mspgcc and the toolchain?

Hi Jens,

Yeah actually I don't think I should be calling it debugging since I know the code works as it is from the example source. What I'm not clear on is how to get it to the device. I used the following procedure: 

start msp430-gdbproxy and set it to listen on a specified port... It works well and says it's listening. 

On a separate terminal, run msp430-gdb and set it to the same port as the proxy... seems to initialize fine and everything

Then I say the following: 

monitor erase all

load led.elf (thats the name of the binary produced by msp430-gcc...)

continue

I'm guessing that final command is the one needed to make the program run on the device, but I don't know if there is another way to do this? My ultimate solution would be to have an option under Eclipse like the one on the IAR Embedded Workbench, where it lets you Download & Debug to the device with a single click. However, I am still unsure as to the whole procedure when it comes to putting the program on the MSP430f2013 that I am using.

As far as the tutorial works, I'd like to get some input on it before actually submitting to the Wiki, I mean some of these solutions might have worked on my system for some reason but may not be universal...

Jens-Michael Gross said:

Which programmer do you use? Which version of mspgcc and the toolchain?

I am unsure what you mean by programmer. I downloaded the mspgcc4 from http://mspgcc4.sourceforge.net/ and currently use gcc-4.x (the one installed by default on Ubuntu 10.04).  

The package mspgcc4 includes many features (not just a compiler) and is based on mspgcc, the only difference - I think - is that it provides support for newer gcc (whereas the original mspgcc went up to gcc-3.x) 

Alvaro Aguilar said:

I am unsure what you mean by programmer.

To just put the file on the device, I use msp430-jtag. It takes the ELF and moves it onto the processor through the programmer. The old binutils only did it with the serial JTAG interface. But the newer processors aren't supported and the USB based programmers aren't too.

I don't know how far the mspgcc4 project has evolved in this respect.

I know that mspgcc4 is still under development and far from being a reliable tool. And it seems that the X branch (which supports the newer, larger processors with >64k) will undergo a major redesign soon.

Personally, I still use the mspgcc 3.23

GDBProxy is a proxy. It is inteded to listen for gsb commands and forward them to the MSP through the JTAG adapter. The problem start hen gdbproxy tries to forward the commands to the MSP.

You should take a look at the MSPGCC mailing list (see at sourceforge). There are different lists for mspgcc and mspgcc4. I know that many issues have been discussed in teh original list as teh mspgcc4 list has been added later. And still much mspgcc4 stuff is discussed there.

I remember several threads about running the mspgcc4 toolchain unde rlinux (or the older 3.23 one). But I don't remember the contents and advices. You should check the mail archieve.

Jens-Michael Gross said:

To just put the file on the device, I use msp430-jtag. It takes the ELF and moves it onto the processor through the programmer. The old binutils only did it with the serial JTAG interface. But the newer processors aren't supported and the USB based programmers aren't too.

This is exactly what I was curious about, which of the utilities to use in order to download the program onto the device and run it. I was just using the msp430-gdb along with the msp430-gdbproxy to communicate with the device and load the software onto it.

I am working with the newer USB based programmers (the eZ430-2013 is that clear USB stick with the USB programmer and a small target board that costs around $20 for the whole thing). I will try the msp430-jtag command with the newer mspgcc4 and let you know what I find. I'm digging up more info on the advantages and disadvantages of mspgcc3 vs. mspgcc4... Once I have more info I will post it and try to include it in my tutorial as well. Anyway, I've had lots of work lately so there hasn't been much advance.

unfortunately, the ez430-f2013 and the more recent ez430 "things" (rf2500, chronos, and launchpad) have significantly different structures.

The F2013 speaks "jtag over serial" over the "serial to usb" converter chip.  Once you have TI's usb/serial driver, it's pretty easy to talk to.

The later dongles add an "application serial port" in addition to the jtag port.  As far as I can tell, this is implemented by having special purpose firmware in the usb/serial chip.  It implements the serial port using a "Communication Device Class" (CDCACM), but it doesn't quite do it in the way that linux or MacOS expects.  The JTAG interface is implemented over a HID device, theoretically making it significantly controllable from user mode programs, but sometimes (ie on Mac) causing the system HID drivers to conflict.

Probably not insurmountable, but the result is that success programming the chips on an ez430-f2013  doesn't mean you'll have success using other similar-lookig programmers.

Alvaro Aguilar said:

I was just using the msp430-gdb along with the msp430-gdbproxy to communicate with the device and load the software onto it.

IMHO, both use the very same TI libraries for the actual communication (msp430.lib and hid.lib, at least under Windows)

When msp430-jtag (mspgcc323) failed to program the new 54xx devices, I tried the newer libs that came with the latest version of IAR compiler. msp430-jtag was still unable to program the new 54xx with the serial programmer, but it was suddenly able to program the older chips using the USB FET.

A rough estimation is that all devices with less than 64k Flash and JTAG should be programmable, for all with above 64k Flash a new machanism is reuired, and some devices don't use JTAG at all but the (2 wwire only) Spy-by-wire protocol which too isn't supporte by msp430-jtag.

Also, msp430-jtag needs to know where the RAM inside the MSP is, and how the flash controller has  to be handled. It is not directly writing the flash, it is writing a small program together with a chunk of data into RAM and executes it. This program then flashes the data from within the MSP.

Unfortunately, much has changed 'under the hood' od teh MSPs. It does not (too much) affect the software side (at least for C), but affects debugging and the flash writing process (the JTAG/SBW interface) as well as the compiler (new opcodes, larger registers etc.).

Things that happen when boosting something beyond the borders of the original design (see the IMB XT and the later AT/386 etc..., the A20 gate, V86 mode, EMS/XMS...).
I think the MSP does well compared to the x86 history.

westfw said:

unfortunately, the ez430-f2013 and the more recent ez430 "things" (rf2500, chronos, and launchpad) have significantly different structures.

I have not tried out the Chronos yet, but it seems like mspdebug would actually work with many of this newer devices. When opening up the man page, it shows capability for ezrf-2500 and others. Like I said, I have only tried this tool with the eZ430-2013 and not anything else, but it seems promising. Here is a set of instructions on how to set it up:

http://mylightswitch.com/2010/06/21/installing-mpsgcc4-and-mspdebug-on-kubuntu-1004/

BTW, I am now almost finished with the MSPGCC tutorial to get it working with Eclipse. I am missing a few final steps on how to get the program onto the device, but other wise it is almost done. Can you guys check it out and tell me what you think?

https://docs.google.com/fileview?id=0BxQ_bK7eJtMfM2FkNjYzNmItNGExOC00NDM2LWEwNGQtNzliZmVjMTU1Yzc1&hl=en&authkey=CJjXrdEG

mspdebug should work with both f2013 and rf2500 style dongles for programming, but they use essentially different drivers.  So (for example) getting rf2500 to work on MacOSX was a whole new experience.  Also, it's not clear that the extra serial port provided by rf2500 will work just because the programming driver does.

I have no experience with Eclipse, so I can't comment much on your instructions.

An interesting possibility has occurred to me: although the ccs4 installer seems to have problems running under Wine, the individual tools (compiler, assembler, linker) are simpler, command-line based things, and it might be possible to run THEM on wine even if the package doesn't work as a whole...  Then you could get the tools (via wine) running under eclipse (running native) and have a toolset that produces identical code to ccs4.

westfw said:

An interesting possibility has occurred to me: although the ccs4 installer seems to have problems running under Wine, the individual tools (compiler, assembler, linker) are simpler, command-line based things, and it might be possible to run THEM on wine even if the package doesn't work as a whole...  Then you could get the tools (via wine) running under eclipse (running native) and have a toolset that produces identical code to ccs4.

I actually got IAR Embedded Workbench to install under Wine without any problems. The version is 5.0.1.254... The only extra thing I did was to create a link to from /dev/ttyUSB0 to ~/.wine/dosdevices/com1 with the "ln -s" command...

However, what you say might be a good possibility for getting the CSS tools to work...

Hie 

Actually , I am also getting similar type of error while attaching TI- launchpad having msp430g2452. I am using Ubuntu 10.10

when I run dmesg command , I get something like this

usb 6-2: new full speed USB device using uhci_hcd and address 2

[15883.606057] /build/buildd/linux-2.6.35/drivers/hid/usbhid/hid-core.c: usb_submit_urb(ctrl) failed

[15883.606074] generic-usb 0003:0451:F432.0002: timeout initializing reports

[15883.606289] generic-usb 0003:0451:F432.0002: hiddev96,hidraw1: USB HID v1.01 Device [Texas Instruments Texas Instruments MSP-FET430UIF] on usb-0000:00:1d.0-2/input1

[15883.606409] cdc_acm 6-2:1.0: This device cannot do calls on its own. It is not a modem.

[15883.606413] cdc_acm 6-2:1.0: No union descriptor, testing for castrated device

[15883.606470] cdc_acm 6-2:1.0: ttyACM0: USB ACM device

[15883.610016] usbcore: registered new interface driver cdc_acm

[15883.610021] cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters