TI MCUs driving me crazy

[MONODA]

I've been using TI mcus for most of my projects recently, specifically the MSP430 line of micrcontrollers. I've been using the low cost Launchpad to program my chips in-circuit. This worked ok at first but recently I've been getting a lot of errors regarding "device not found" etc even though everything is connected correctly. I wonder if this is because of the Launchpad, the IDE (Code Composer Studio and IAR workbench both crash on me quite a bit).

Because of these problems I've considered moving over to a different line of low cost MCUs. I have also considered purchasing a higher quality programmer, but I am sceptical that this will solve the issue.

Since I am a student, I am reluctant to make any purchases over $50 without some serious thought!

If anyone with expereicne with the MSP430s and their programmers and IDEs I would much appreciate some advice or tips.

Also, if anyone can recommend another line of low cost low-power micronctrollers I would highly appreciate it!

Thanks!

[8086]

PICKit 3 and a PIC of your choice.

[lgbeno]

I think all parts are going to have similar issues over time, my advice is to stick with TI.  Maybe check out energia as a alternate to cvs if you want a arduino like experience.

[andyturk]

Personally, I vastly prefer ARM Cortex to MSP430 (STM32 in particular). The MSP430 works fine until you blow out the address space and then things get more difficult. On the other hand, if you're writing small programs and you need a dual in-line package, MSP430 is just fine.

Check out any of the STM32 Discovery boards for an ARM alternative. The cheapest is about $10 (USD) and includes a built-in programmer, which works quite well. In my experience, TI's JTAG setup on the MSP430 isn't the greatest. I've got two USB-FETs on my desk at the moment which have different firmware for different toolchain versions. Minor releases in Code Composer Studio (TI's IDE) update the firmware too, which complicates matters sometimes.

One of the best things about the ARM ecosystem is that there are several nice open source toolchains available. They work well, they're free, and if you're not a jerk, you can get technical questions answered on the mailing lists very quickly.

Going with MSP430 essentially locks you into TI's toolchain (or one of the proprietary alternatives). There is mspgcc/mspdebug, but setting those up is not a beginner-friendly project.

[ptricks]

MSP430 and STM processors are two of the most unfriendly processors a beginner could pick. It isn't that the chips are not capable or low cost, it is the lack of information that exist that is targeted at beginners.   When I want to get someone started in embedded hardware I point them to AVR, PIC, NXP. A decent ARM board to get started is the LPC1347, retails for around $20 and doesn't need any external programmer.
http://www.embeddedartists.com/products/lpcxpresso/lpc1347_xpr.php

[MONODA]

I have a lot of experience working with the MSP430 as well as freescale microcontrollers so I am quite far from being a beginner.

My main issue with the MSP430 is the number of issues that arise due to either the IDE or the programmer I am using. Crashes with the IDE are frequent and I often stubborn problems with loading code onto the chip. Of course, this is incredibly frustrating, especially when I have a deadline that I need to meet.

My question basically comes down to: should I expect to run into these tedious issues with any microcontroller I use or are there others that support a much wider scope of hardware and software?

I ask this because I don't want to spend the time and money moving to another family of microcontrollers only to realize that I have the same issues there.

Any thoughts or comments are welcome!

[jmole]

Check out the PSoC Series by Cypress. I highly recommend their PSoC 5 LP chips. Cortex M3, 24 mini FPGA blocks, 4 op amps, 2x 1MSPS SAR ADCs, and much more.

[nctnico]

I have a lot of experience working with the MSP430 as well as freescale microcontrollers so I am quite far from being a beginner.

My main issue with the MSP430 is the number of issues that arise due to either the IDE or the programmer I am using. Crashes with the IDE are frequent and I often stubborn problems with loading code onto the chip. Of course, this is incredibly frustrating, especially when I have a deadline that I need to meet.

That is why I don't debug microcontrollers; it takes time to setup and the vendor provided tools usually are crappy. I use GCC to compile, Eclipse for the IDE and a command line interface over a serial port. I debug complex parts of the software on a PC and the rest of the debugging/verification gets done by simply typing commands. BTW I use the same libraries for both MSP430 and ARM.

[TheDirty]

Though I don't have any issues with CCS, I can understand crashes with that since it's much more 'patched together', but IAR crashes would be strange.

I have had off and on issues with the spy-by-wire programmers which don't play nice with some other USB drivers, but nothing that hinders me.

[oPossum]

The only problem I have with CCS is that it becomes quite sluggish after running for a few weeks and I have to restart it.  Does not crash, and no problems programming/debugging with Launchpad or MSP-FET430UIF.

You can use the CCS compiler from the command line if you want.

[MONODA]

That is why I don't debug microcontrollers; it takes time to setup and the vendor provided tools usually are crappy. I use GCC to compile, Eclipse for the IDE and a command line interface over a serial port. I debug complex parts of the software on a PC and the rest of the debugging/verification gets done by simply typing commands. BTW I use the same libraries for both MSP430 and ARM.

This sounds interesting, so do you use MSPGCC and GDB?

[nctnico]

I use MSPGCC but I never use GDB on a microcontroller.

[andyturk]

I use MSPGCC but I never use GDB on a microcontroller.

Can you say a little more about how you approach mcu debugging?

I'm working on an MSP430 project right now and avoid the debugger (CCS) as much as possible. I've got a command shell that talks via a debug uart, but that only works when the rest of the system is in decent shape. I.e., if something bad happens in an ISR, all bets are off.

[nctnico]

There is not much to it. I usually incorporate some status commands. In some cases I make an I/O pin high during an interrupt which does a lot of processing so I have an idea on how much time is spend in the interrupt using an oscilloscope. All my designs also have an LED which blinks in a 1Hz rhythm. I always have a tick counter incremented by a timer interrupt. From the main loop (which executes all the modules) I use the tick counter to blink the LED. This gives a lot of information on whether the software runs or not. If a change in the software causes the LED to stop blinking something went seriously wrong. On ARM devices (which usually have more complex firmware) I implement the fault handlers and use direct UART routines (without interrupts) to print the stack pointer and a short stack trace. This usually gives enough information on where the program went wrong.

A blinking LED is also very handy for field service engineers. You can ask the field service engineer whether the LED is blinking, on or off and what happens if he power cycles the system. This usually answers the question whether the device is faulty or it is a cabling or power problem.

[westfw]

should I expect to run into these tedious issues with any microcontroller I use

I "follow" half-a-dozen microcontroller families, and I don't think any of them have an IDE that everyone thinks is wonderful.
"crashes", "bloated", "too complicated", "too simple", "too slow", "new version missing features of previous version", "too expensive", etc, etc.  I would not expect moving to a new family to solve "tools" problems.

What have you done to try to get your bugs and problems fixed?  Reported the problems to TI?  Opened discussions on the assorted MSP430 forums?  Made sure you're running the latest versions of IDE, Compiler, internal firmware, etc?  (In particular, the TI USB/Serial chip used on the launchpad has a poor reputation, and they're stretching its capabilities (and those of some host-side drivers) by having it implement two devices, and it will (can) download its firmware from the host...)

OTOH, I'm also a command-line sort of guy.  One IDE might be OK, but having half-a-dozen that are each complex and different would be hell.    I've used gdb to talk to the msp430 simulator running msp-gcc code, which is pretty neat...

(The other thing to look at would be one of the multi-platform IDEs like IAR Workbench (which supports something like 22 processor families.)  Not everyone is happy with it, either, and "full" versions cost big bucks, but at least you could hope for some commonality of annoyances!)

[andyturk]

On ARM devices (which usually have more complex firmware) I implement the fault handlers and use direct UART routines (without interrupts) to print the stack pointer and a short stack trace. This usually gives enough information on where the program went wrong.

That's a really good idea. If you hit the fault handler, it's probably safe to reset the uart and dump out some info (busy-waiting for each byte to be sent). You just need to have your serial cable hooked up to see it.

I like blinkenlights too. I've got an assert macro that turns on an LED when an assertion fails. It also adds a constant to a counter that's decremented when >= 0 in the main loop. When the counter gets to zero, the main loop turns off the LED. The net effect is like a pulse stretcher for failed assertions.

[nctnico]

(The other thing to look at would be one of the multi-platform IDEs like IAR Workbench (which supports something like 22 processor families.)  Not everyone is happy with it, either, and "full" versions cost big bucks, but at least you could hope for some commonality of annoyances!)

Eclipse just does that but is not limited to any controller you could think of but also supports about any language you could come across. Debugging a PHP program works the same as debugging C code on a microcontroller.

[jmole]

should I expect to run into these tedious issues with any microcontroller I use

I "follow" half-a-dozen microcontroller families, and I don't think any of them have an IDE that everyone thinks is wonderful.
"crashes", "bloated", "too complicated", "too simple", "too slow", "new version missing features of previous version", "too expensive", etc, etc.  I would not expect moving to a new family to solve "tools" problems.

I hate to be a nagging nancy, but seriously: download PSoC Creator here: http://www.cypress.com/?id=2494 . It is full featured, completely free, has never, ever, ever, crashed on me in 4 years of development, supports Verilog and C on the same chip, plus lets you throw down Op Amps, Comparators, ADCs, DACs, multiplexers, and more onto any pin on the MCU.

It's a free download. Can't hurt to try it.  I've got a (very) basic tutorial here:

[westfw]

Eclipse just does [many different CPU families]

It does, theoretically (as do netbeans and codeblocks?), but support for most microcontrollers seems to come in the form of a highly-customized, for-$, version provided by some vendor.  For instance, the TI CCS that the OP is (presumably) complaining about is Eclipse-based.

PSoC Creator

PSoC seemed pretty cool, but I got disillusioned by the long gap between the time I took the cypress "intro to PSoC5" class, and the time PSoC5 chips (ARM) actually appeared at distributors :-(  The PSoC1 (Cypress proprietary, and I've heard "pretty sucky") and PSoC3 (8051) were less interesting, and (last I looked at them) supported much less customization of the hardware side.  (Did that get changed?  IIRC they let you plunk down various standard peripherals composed from their logic blocks, but didn't let you configure them at more primitive levels.)  (thanks for the pointer to your tutorial though.)

[jmole]

Eclipse just does [many different CPU families]

It does, theoretically (as do netbeans and codeblocks?), but support for most microcontrollers seems to come in the form of a highly-customized, for-$, version provided by some vendor.  For instance, the TI CCS that the OP is (presumably) complaining about is Eclipse-based.

PSoC Creator

PSoC seemed pretty cool, but I got disillusioned by the long gap between the time I took the cypress "intro to PSoC5" class, and the time PSoC5 chips (ARM) actually appeared at distributors :-(  The PSoC1 (Cypress proprietary, and I've heard "pretty sucky") and PSoC3 (8051) were less interesting, and (last I looked at them) supported much less customization of the hardware side.  (Did that get changed?  IIRC they let you plunk down various standard peripherals composed from their logic blocks, but didn't let you configure them at more primitive levels.)  (thanks for the pointer to your tutorial though.)

Cypress took their sweet time getting the psoc 5 to market, but the psoc 5 lp (aka the psoc 5 living up to its original specs) is absolutely phenomenal (and finally priced reasonably). I remember trying to work with the original psoc 1 IDE, called psoc designer; creator (for psoc 3/4/5) is light years ahead of it. The best embedded IDE I've ever used, by a long shot.  Plus, what other mcu can act as a real analog mux, while also running some custom verilog?

[nctnico]

Eclipse just does [many different CPU families]

It does, theoretically (as do netbeans and codeblocks?), but support for most microcontrollers seems to come in the form of a highly-customized, for-$, version provided by some vendor.  For instance, the TI CCS that the OP is (presumably) complaining about is Eclipse-based.

That is the wrong way. Just point to the proper GCC compiler and off you go.

[westfw]

Just point [eclipse] to the proper GCC compiler and off you go.

That does not appear to be the way that microcontroller vendors think.  What about simulation, debugging, device programming, chip configuration (fuses), device selection, communications and so on?  "Arduino" has to be one of the most primitive IDEs available; it has six major buttons "compile", "upload", "new", "open", "save", and "serial monitor."   A normal eclipse install omits a third of those functions!

[nctnico]

Simulation: compile for the PC and debug
Programming & fuses: use your favorite programming tool
Debugging: get a remote GDB going over a debugging capable interface
Serial monitor: any terminal emulation program

A lot of vendor provided tools are intended to get a blinking led or 'hello world' project going NOT for creating anything real.

[westfw]

So how do I do the FPGA configuration for those PSoC devices?
Your advice boils down to "use separate tools instead of an integrated environment."  That may be fine advice, but...  Have you ever actually tried to put together a development environment (integrated or otherwise) for some embedded microcontroller, starting with the vanilla distributions of Eclipse, gcc, gdb, and etc?  It's pretty painful.

A lot of vendor provided tools are intended to get a blinking led or 'hello world' project going NOT for creating anything real.

I disagree.  I mean, MANY such tools are now based on Eclipse or some other "well known" open source IDE.  I think they usually fail along the lines of "trying to provide every feature than anyone in any sized company can develop for any chip we make."

We may have to agree to disagree, though.

[jmole]

So how do I do the FPGA configuration for those PSoC devices?

Basically you create a block-diagram component, with some input and output pins, which correspond to input/output pins in your verilog.

This video is a good (but slow) intro: http://www.cypress.com/?rID=40330

I'm planning on putting together a video about the process fairly shortly. Will share when it's done.