TI MCUs driving me crazy - Page 1
Forum section: electronics / general

author: MONODA
author_rank: Contributor
timestamp: April 30, 2013, 05:13:06 pm
content: 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!

author: 8086
author_rank: Super Contributor
timestamp: April 30, 2013, 05:19:25 pm
content: PICKit 3 and a PIC of your choice.

author: lgbeno
author_rank: Frequent Contributor
timestamp: April 30, 2013, 06:26:55 pm
content: 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: April 30, 2013, 08:09:58 pm
content: 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.

author: ptricks
author_rank: Frequent Contributor
timestamp: April 30, 2013, 08:27:10 pm
content: 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

author: MONODA
author_rank: Contributor
timestamp: April 30, 2013, 08:42:15 pm
content: 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!

author: jmole
author_rank: Regular Contributor
timestamp: April 30, 2013, 09:52:23 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 01, 2013, 08:26:09 am
content: Quote from: MONODA on April 30, 2013, 08:42:15 pmThat 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.

author: TheDirty
author_rank: Frequent Contributor
timestamp: May 01, 2013, 01:12:46 pm
content: 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.

author: oPossum
author_rank: Super Contributor
timestamp: May 01, 2013, 02:26:18 pm
content: 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.

author: MONODA
author_rank: Contributor
timestamp: May 01, 2013, 04:57:01 pm
content: Quote from: nctnico on May 01, 2013, 08:26:09 amThis sounds interesting, so do you use MSPGCC and GDB?

author: nctnico
author_rank: Super Contributor
timestamp: May 01, 2013, 06:38:50 pm
content: I use MSPGCC but I never use GDB on a microcontroller.

author: andyturk
author_rank: Frequent Contributor
timestamp: May 01, 2013, 09:54:29 pm
content: Quote from: nctnico on May 01, 2013, 06:38:50 pmCan 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 01, 2013, 10:16:20 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: May 02, 2013, 01:23:25 am
content: QuoteI "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!)

author: andyturk
author_rank: Frequent Contributor
timestamp: May 02, 2013, 02:53:43 am
content: Quote from: nctnico on May 01, 2013, 10:16:20 pmThat'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.

author: nctnico
author_rank: Super Contributor
timestamp: May 02, 2013, 06:57:46 am
content: Quote from: westfw on May 02, 2013, 01:23:25 amEclipse 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.

author: jmole
author_rank: Regular Contributor
timestamp: May 02, 2013, 07:44:55 am
content: Quote from: westfw on May 02, 2013, 01:23:25 amI 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:

author: westfw
author_rank: Super Contributor
timestamp: May 02, 2013, 09:11:55 am
content: QuoteIt 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.QuotePSoC 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.)

author: jmole
author_rank: Regular Contributor
timestamp: May 02, 2013, 09:47:39 am
content: Quote from: westfw on May 02, 2013, 09:11:55 amCypress 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?

author: nctnico
author_rank: Super Contributor
timestamp: May 02, 2013, 07:00:54 pm
content: Quote from: westfw on May 02, 2013, 09:11:55 amThat is the wrong way. Just point to the proper GCC compiler and off you go.

author: westfw
author_rank: Super Contributor
timestamp: May 03, 2013, 02:20:22 am
content: QuoteThat 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!

author: nctnico
author_rank: Super Contributor
timestamp: May 04, 2013, 12:15:48 am
content: Simulation: compile for the PC and debugProgramming & fuses: use your favorite programming toolDebugging: get a remote GDB going over a debugging capable interfaceSerial monitor: any terminal emulation programA lot of vendor provided tools are intended to get a blinking led or 'hello world' project going NOT for creating anything real.

author: westfw
author_rank: Super Contributor
timestamp: May 04, 2013, 02:04:23 am
content: 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.QuoteI 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.

author: jmole
author_rank: Regular Contributor
timestamp: May 04, 2013, 02:49:42 am
content: Quote from: westfw on May 04, 2013, 02:04:23 amBasically 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=40330I'm planning on putting together a video about the process fairly shortly. Will share when it's done.

author: westfw
author_rank: Super Contributor
timestamp: May 04, 2013, 05:54:37 am
content: QuoteI know how to do it in PSoC creator (in theory, anyway.) I was wondering how nctnico planned to do it in his standard eclipse environment...I see that Cypress has a low-cost PSoC4 board ("compatible with Arduino shields"; snort.) Cool.One of the things that someone in the Cypress class I attended pointed out is that using the same IDE for writing the software AND configuring the FPGA cells would break the "common" separation of HW and SW engineering teams at many companies. An interesting (and rather sad) observation.

author: nctnico
author_rank: Super Contributor
timestamp: May 04, 2013, 02:26:31 pm
content: Quote from: westfw on May 04, 2013, 02:04:23 amI don't know about the Psoc devices. But to get going you install CDT (Eclipse C development tools), install GCC for the microcontroller you want to use, create a new Eclipse project, open the settings and replace GCC with the name of the compiler you want to use and the same goes for the includes and library paths. This is not difficult at all.

author: jmole
author_rank: Regular Contributor
timestamp: May 05, 2013, 01:09:11 am
content: Quote from: nctnico on May 04, 2013, 02:26:31 pmHaving to set up the library paths each time you create a new project seems like a pain in the ass. I mean, if you're on linux, and there's simply no other options, then sure, do what you will. I prefer an IDE that works straight out of the box, and that works well. That's why I use PSoC Creator.Unfortunately I've got a project on the horizon that involves something like 1024 or more digital output pins, so I'm going to have to make a foray into the world of real FPGAs, and their ages-old design environments.Also, I put together a very quick tutorial on the verilog integration in Creator, you can see it here:

author: nctnico
author_rank: Super Contributor
timestamp: May 05, 2013, 08:27:20 am
content: If you are developing with C / C++ then about every project needs library paths. Besides you can copy & paste them from a previous project. I have several template projects for various microcontrollers. I usually start a new project by copying one of those.

author: andyturk
author_rank: Frequent Contributor
timestamp: May 05, 2013, 04:44:12 pm
content: Quote from: jmole on May 05, 2013, 01:09:11 amI'm with you on the "assembly is (mostly) useless" front, but I'll take a well-crafted Makefile over an IDE any day.Also, I put together a very quick tutorial on the verilog integration in Creator, you can see it here:Very cool. My freesoc should arrive next week. Looking forward to playing with it.