17 May 2010

Writing a first program

The typical "Hello, World!" of microcontrollers is a blinking LED. The F2132 target board has an LED connected to one of the pins on port 1 (P1.0, pin 21) by a jumper. Here's what a typical C program for this looks like:

/* blinkyF2132: test program toggling an LED connected to P1.0 on the
 * MSP430F2132.

#include <msp430x21x2.h>

void main(void) {

int i;

P1DIR = 0x01;
P1OUT = 0x00;

for (;;) {
P1OUT ^= 0x01;

for (i=0; i<0xFFFF; i++) {
} // delay
} // infinite loop

} // main

  • The first thing to note is the included header file; all msp430 compilers come with a collection of these files that define specific tools and behavior for the various families of the controllers. In this case, since I am using an F2132, I use the x21x2 family header. (Edit: looking at the header file included in CCS4, this format for the header file is considered legacy. The preferred usage would be specific to the chip itself, so in this case you would include the msp430f2132.h header file.)
  • WDTCTL, P1DIR, P1OUT and the like are all convenient keywords defined in the header file.
    • WDTCTL points to the word (2 bytes) controlling the watchdog timer. This timer resets the chip after a certain amount of time has passed. To keep our program running, it needs to be disabled. The 8 least significant bits (0 through 7) of WDTCTL control the behavior of the watchdog timer. Bit 7 specifically puts the timer on hold if set to 1. In the header file, WDTHOLD is defined to be a 2 byte value with only the 7th bit set to 1 (ie. 0b0000000010000000, or in hex, 0x0080). By writing WDTHOLD to WDTCTL, we turn off the timer.
    • WDTCTL only uses 1 byte for its control; the 8 most significant bits are set up as a key to prevent a program from inadvertently changing the configuration. Hence, to write to WDTCTL you need to include a password of sorts. This password is the value 0x5a, and the header defines WDTPW to be 0x5a00. By adding this value to WDTHOLD you end up writing the value 0x5a80 to WDTCTL--which satisfies the necessary key and sets the hold bit to 1. (Note that you could also use WDTPW | WDTHOLD instead of adding them. They have the same effect in this case, but the TI examples use +, so I chose to use that convention.)
    • Each port can configure each of its 8 pins to be inputs or outputs individually. On the target board, the LED is on P1.0, so P1DIR is set to have bit 0 to be the value 1 (output) and each of the other bits 0 (input). Writing 0x01 (0b00000001) to P1DIR configures it this way.
    • P1OUT controls the digital values on the output pins of P1. In this program, 0x00 sets the outputs all to zero, and 0x01 sets all but pin 0 to zero with pin 0 at 1. The LED is connected with its cathode at ground, so a high value on P1.0 turns on the LED. Thus 0x00 is off, 0x01 is on.
  • After setting up the configuration of the MCU, the program then enters the infinite loop: for (;;) { }. This step may seem odd at first, but since we want our controller to keep working, we can't have a program that terminates. Practically, without the loop the MCU would then continue trying to execute statements in the next memory spaces, eventually reading well beyond the actual program to unpredictable results.
  • Inside the infinite loop, the program changes the value on P1.0. The ^, which is the C symbol for the exclusive or operation, turns the LED on if it is off, and off if it is on. Another for loop causes a delay between toggles on the LED. The length of the delay depends on how far the iterator i has to count. (It also depends on the frequency at which the MCU is operating; a faster clock speed makes the iteration count faster.)

This program is very simple, and not really useful for much other than to reassure you that everything works right and that you can actually program the msp430. Below is a short video of my target board running the program. There are certainly more elegant ways to do this trivial task, but this method is a good way to start and doesn't require much understanding of the MCU itself.

Reader Exercise: Write a similar MSP430 program using the MSP430F2001 to alternate blinking LEDs on ports P1.2 and P1.7 (ie. LED 1 is on, LED 2 is off. After some time, they switch to LED 1 off, LED 2 on. The F2001 is a 14 pin MSP430 that comes in PDIP, TSSOP, and QFN packages. P1.2 is pin 4, P1.7 is pin 9.)


A few options exist for programming the MSP430.  A number of professional compilers are available, but for easy home and hobby use there are also free versions.

  • IAR Embedded Workbench Kickstart (Referred to as EW430 in MSP430 Microcontroller Basics by John H. Davies)
    • The free version is limited to 4 kb code size
    • Works in Windows (32 and 64 bit versions)
  • Code Composer Studio v.4 (CCS4)
    • Free version is limited to 16 kb code size
    • Works in Windows (32 and 64 bit versions)
    • Unlimited code size, as it's open source software
    • Works in Linux or Windows under Cygwin (32 bit)
I'll be working with CCS4, at least to start.  On a Mac system, the MSP430 is programmable by using any of the windows software through a virtual windows installation using VMWare Fusion.  Unfortunately, VMWare requires a license, and the free, open source VirtualBox does not work with the USB FET.  MSPGCC has been ported to Mac, though.

While I would prefer working in a linux environment, it seems mspgcc is difficult to use because of the state of msp430-gdbproxy, the software that communicates through the FET.  It does not yet support some of the newer families of MCUs, and takes a good deal of effort to get working properly.  It also does not seem to support 64 bit systems yet.

For now, CCS4 works quite well and so will be the IDE I use.  Very little of what will be documented here depends specifically on the environment, however, and so the choice is pretty arbitrary.  The 16 kb limit might sound small, but typical MCU programming is actually quite dense, and so a lot of projects can easily fit into that limit.

05 May 2010


TI makes a large variety of types and packages for the MSP430, from a basic, 14-pin PDIP to a 113-pin BGA Microstar. Selecting the right MCU depends on a number of factors, including the number and types of peripherals and devices that need to be controlled.

For the initial experiments, we'll use the MSP430F2132 and the 20/28 pin target board produced by TI.  These can all be purchased in a single package, and can include the MSP-FET430UIF flash emulation tool for programming the MCU.  This target board works with the x21x1 20-pin TSSOP variations and the x21x2 28-pin TSSOP variations.  The package comes with 2 F2132's, which are the largest of the chips usable in this board.  The x21x2 is useful for basic projects as it includes most of what could be needed, including an analog to digital converter.  Nearly everything done at this site will be doable on nearly any of the MSP430's, however.  Sometimes a small chip (even the new and inexpensive G-series types) will be sufficient, and some of the larger chips (with more pins) may be helpful in future projects.

The F2132 features:
  • 16 MHz clock (at full voltage)
  • 8 kb flash memory
  • 512 b RAM
  • 24 General Purpose Input/Outputs
  • 10-bit SAR A/D Converter
  • Universal Serial Communication Interface (communicates via UART, LIN, IrDA, I2C, or SPI)
The target board is a useful format for testing without needing to create a custom PCB or solder the MCU to anything.  It includes a socket designed to hold the TSSOP package.  Included are header pins (male and female) to attach on either side of the socket as seen in the photo above.  I've chosen to use the female pins, which allows me to connect wires to devices easily.  It also provides some protection from an accidental short from a stray wire bridging two pins that the male pins would not provide.  The general rule of thumb in rockets is that anything that is powered when disconnected (intentionally or accidentally) should be female, and that's the convention used here.

Also on the board is a place to connect a 32.678 kHz crystal for timing.  The MCU has excellent timers internally, so the crystal is not always essential; it's good to have for time critical applications, though.  The kit includes a 12.5 pF surface mount crystal, though one flaw in the board design is that there is no convenient way to ground the crystal case.  One option might be to solder a wire to the case and fit into the via that connects to ground.  The crystal included in my kit actually broke off of its fine leads when I was playing around with figuring out how to attach it, so I have not put a crystal on my target board yet.  Plated through hole form factors may be usable since the mounting place for the crystal on the target board is PTH.  A quick note about the capacitance of crystals--it seems the MSP430, or at least newer versions of it, are able to set the load capacitance internally via software, so other capacitances may be used; I'll use 12.5 pF since that's what came with the kit initially.

In addition to the F2132, some experiments will make use of the MSP430F5438 and the Experimenter Board made by TI.  The F5438 is the chip being used in my research, and so this combination gives me a way to program that particular chip while also providing an environment with lots of external devices and controls to use in experiments, including an LCD, accelerometer, and various interface devices.

Both boards can be powered by the FET or externally.  A future post will look into various options for powering an MSP430 project, and many experiments will simply use a pair of alkaline AA batteries (3.0 V).  Note that two AA's do not provide sufficient voltage for the processor to run at the full 16 MHz.

The equipment described here will not necessarily be appropriate for everyone, but are a convenient and useful place for me to start.  As I stated earlier, the ideas approached here will be useful for other projects using different chips and boards as well.  Next time we'll take a look at the software needed and start loading a simple program onto the chip.