Posted: January 14, 2023

Introduction

Here's some "getting started" guide on programming MSP430 chips using naken_asm as an assembler and mspdebug to flash the chips and debug them. This tutorial will hopefully be useful for someone who:

• Comes from the software world and wants to know how microcontrollers work.
• Want to learn about the different features of MSP430's that can be used.
• Learn some simple MSP430 assembly.
• Learn how to program these chips without a big IDE to download.

Concepts that will be discussed on this page:

• Microcontrollers
• MSP430 CPU
• Assembling and Running Code
• Debugging Code
• Clock Sources
• Peripherals
  • Digital I/O
  • Timers
  • Analog to Digital converters (ADC)
  • UART
  • SPI
  • i2c
• Using Transistors

If something needs more explanation or such, feel free to send me an email so I can add to this page. I've been tempted to do a video for this too, but not sure if that's useful.

Microcontrollers

A microcontroller is basically a microchip that contains a CPU, RAM, flash memory (to hold the firmware / computer program), peripherals (digital I/O, timers, analog/digital converters, SPI, i2c), and more all embedded in a single chip. Most chips run between 1MHz to 20MHz in speed and have 8, 16, or 32 bit instruction sets.

Most of the projects on this website use either Atmel AVR8 (ATtiny85, ATtiny2313) or MSP430 (MSP430G2553, MSP430G2231). So how do I pick which chip to use? Each of these chips have different features and different limitations. The MSP430 have the Launchpad for a really easy debugger (as will be shown later) while the Atmel chips are really not that easy, especially on Linux. Atmel chips have an advantage that they can run at +5v or 3.3v while MSP430 is 1.8v to 3.3v. Which means interfacing with 5v devices is much much simpler with the Atmel chips. The ATtiny85 is only 8 pins (four on each side) making it really nice for very small circuits. The Atmel AVR8 chips have an 8 bit instruction set while the MSP430 is a 16 bit instruction set.

Above is both an MSP430G2231 and MSP430G2553. The first obvious difference is the MSP430G2231 has only 16 pins while the MSP430G2553 has 20. If not that many pins are needed for the circuit, it's probably better to pick the smaller chip. However, the MSP430G2553 not only has more pins, but it also has things like a hardware UART. The functions of the pins are almost identical so there's a possibility that if the circuit has an MSP430G2553 in it, the chip can be drop in replaced with the smaller MSP430G2231. Just be careful with SPI, the data pins are swapped between the two chips. Another important difference between the chips is the MSP430G2553 has 16 kB flash / 512 bytes RAM while the MSP430G2231 has 2kB flash / 128 bytes RAM.

The chips themselves come in different packages, where the package is the casing that the chip is covered by. When ordering raw chips from a site like Mouser, make sure to look for PDIP16 or PDIP20 packages like the ones in the picture above. These packages are through-hole and can be easily placed in a breadboard. They sell these chips in surface mount packages which have smaller pins and must be soldered on top of a board created for that packaging.

MSP430 Core

Wikipedia has a list of MSP430 instructions along with their opcode bit encodings. A quick list of the instructions are:

MSP430 assemblers also understand "pseudo-operations" which don't really exist in the instruction set above, but will output an equivalent instruction:

These are instructions that despite having a name like "inc" is really just an alias for "add". So assembling:

Will actually output the instruction:

The MSP430 has 16 registers labeled PC (program counter), SP (stack pointer), SR (status register), CG (constant generator), and r4 through r15. Registers r4 to r15 are fair game, but the first four registers are rarely accessed directly. The CG register is never accessed by the developer, it's used by the assembler so that when using 1, 2, 4, 8, or -1 are used as an immediate value, the instruction can be encoded as 16 bits. For example:

In the two examples above, the first sets register r8 to the number 1. This can be done as a single 16 bit encoding and only takes 1 CPU cycle to execute. The assembler actually encoded the source register as "CG" and the 2 bit source addressing mode flags to 01 telling the CPU to load a constant of 1 into the r8. In the second example, #3 cannot be generated by the CG register, so the immedate value is the next 16 bits after the instruction causing it to use 32 bits and take 2 cycles to execute.

Most instructions can take a .b or .w flag that let the assembler know if operation should be 8 bit or 16 bit (word). 16 bit accesss to memory are done little endian (least significant byte first). So if the program writes 0x1234 as 16 bit to location 0x200 in memory, the memory address 0x200 will contain 0x34 and address 0x201 will contain 0x12. There are several addressing modes for every instruction, all can be used in the source operand but only 2 of them can be used for the destination.

Note in the mov.w #5, r9 and mov.b #5, r9 instructions are basically identical since they will both instructions take up 32 bits as opcodes. All instructions will be a multiple of 16 bits, so even though moving a byte with a value of 5 is only 8 bits, the 16 bit little endian value of 0x05 0x00 will still be written to program memory. Also, if it's not obvious the syntax of the chip is <instruction> <source>, <destination>.

Any instruction that treats a register as 8 bits will clear the upper 8 bits of the register.

After those two instructions run, r8 will hold the value 0x0035.

Another thing to notice is when using an address as either a source or destination, it can be done with an & infront or without (in the above &0x200 vs 0x200). The difference is & uses the address as an absolute address. If the code is disassembled, 0x200 with be in 16 bits after the opcode. Without the & it it's assembled using an offset from the current instruction to the address. The purpose is using & or without is to make the code relocatable. Any reference to a hardware register should have & while reference to data in flash memory could be done without so if the code is memcpy()'d to a different address, it will still execute the same.

Hooking Up The Chips

Each of these chips has a black casing and a number of pins coming out of the bottom. Each one of those pins has a specific function and to figure out what they do, the manufacturer of the chip will show a pinout map in their datasheets. Since links can move, there won't be any links to the Texas Instruments PDF's for the MSP430, but doing a web search for "msp430g2553 datasheet" will bring up a page that has both the MSP430G2553 datasheet and the MSP430G2xx Family User Guide. Both are needed. The MSP430G2xx Family User Guide is for all chips that start with the number 2 (including the MSP430G2231) while the MSP430G2553 PDF will have the information specific for this chip. Below is both the chip and the pinout:

The first thing to notice is all the pins are numbered from 1 to 20. The top left pin is always pin 1 and the top right pin is always the highest number pin. The very top of the chip has a notch carved out on it. This is how to tell where the top of the chip is. On some chips they will instead carve out a circle next to pin 1, but this one has the notch.

Another thing to notice, most of those pins have multiple labels separated by a slash. For example, pin 2 has P1.0 / TA0CLK / ACLK / A0 / CA0. This pin can be configured to do multiple things (not at the same time of course) by placing a value in a configuration register. By default on this chip, the pins are configured to be P1.0 to P1.7. Pins 8 to 13 default to P2.0 to P2.5. Table 2 in the MSP430G2553 PDF will explain what all these functions are. More on this later.

There is a minimum of 3 pins that are used to "turn on" the chip. DVcc must be connected to a positive voltage source, 1.8 is minimum and 3.3v is maxiumum. Hooking this chip up to more than 3.6v will cause it to get warm and can cause it to do weird stuff including damaging it. DVss needs to be connected to GND of the power source (the negative terminal of a battery). The D in DVcc / DVss means digital. Some chips do this because they might have an AVcc power connection for analog circuitry. Also, some chips will label Vcc as Vdd and Vss as just GND. In order for this chip to run, the /RST chip should be connected with a 47k ohm resistor to DVcc. Why 47k ohms? Because the datasheet says so. The MSP430G2 Launchpad schematic also shows 47k ohms with a 1000pF capacitor to GND. I usually leave off the capacitor.

Above shows an MSP430 in a breadboard. The resistor is connected from /RST to DVcc. The battery clip holds 2 AAA batteries which are 1.5v each or 3.0v total when hooked up in series. The +3v wire is connected to pin 1 on the microcontroller while GND is connected to pin 20. If there was a program on this chip and there were batteries in that pack it would start executing. As a tip, figure out a good color coding for wires and stick with it to make circuits easier to read. For example red = +v, black = gnd, blue = data, white = chip select, yellow = clock, etc.

The next step here would be to hook up something interesting to the chip and the MSP430G2 Launchpad as a debugger.

The picture above shows the MSP430G2 Launchpad with the chip removed from the socket. At the bottom right is a black jumper connected to GND and a red wires connected to Vcc. Those two wires will be connected to DVcc and DVss on the breadboard. At the upper right there are a set of jumpers with their function silk screened on the board. The RST and TEST jumpers have been removed and a blue wire is connected to the far side of TEST and a green jumper connected to RST. Those two pins wires will be connected to RST and TEST pins on the MSP430G2553. These allow the Launchpad to act like a debugger to the chip using a Spy-By-Wire protocol. Note that if the MSP430G2553 is powered separately, do not connect the red wire to Vcc, but the GND wire must be connected to the circuit.

Above is the breadboard being powered by the launchpad. At the top of the bread board connects the red / blue rails on either side so that both sides of the breadboard have +3.3v and GND connections. DVcc and DVss are connected to power and TEST / RST are connected to the blue / green wires to the launchpad. P1.0 and P1.6 are connected to a 180 ohm resistor to an LED to ground.

Above is another view of the circuit.

The pins when configured as digital I/O (on some chips called general purpose I/O or GPIO) are labeled P1.0 to P1.7. These are pins 2 to 7 for P1.0 to P1.5 and pins 14 and 15 for P1.6 to P1.7. As digital I/O they can be inputs or outputs. If configured as outputs they will have a voltage on them or 0 volts. The voltage they will output is the same voltage as DVcc, so if the chip is running at 3.3v, then they will output 3.3v when set to 1. When set to 0 they can actually sink voltage, so if there is an LED hooked up to them backwards (from 3.3v through the LED in the correct direction to GND) they will turn on when the output is 0 and turn off when the output is 3.3v.

A few things to note about the LED part of the circuit. The first is LED only work in one direction. If you put +3.3v on the short pin and GND on the long pin, they won't turn on. But if you put 3.3v on the long pin and 0v on the short they will. The next thing to note is an LED needs to limit the amount of current. These cheap LEDs on the circuit above can't have more than 20mA of current through them. The last thing to note is there is a limit on the amount of current you can pull from a microcontroller without the possibility of either glitches in the code or damage to the pin. Most microcontrollers limit to 20mA, I believe in this chips case you can't pull more than 20mA on all the pins combined.

To limit the amount of current pulled from the microcontroller a resistor is used. The formula is ohms' law current = voltage / resistance. Sending a voltage through a diode causes a voltage drop too, in this case it's around 1.7v for this LED, so the forumula is: (3.3v - 1.7v) / 180 ohm = 0.0088A or ~9mA

If the device (LED, motor, etc) needs more current to operate, a transistor can be used. A transistor can act like a switch so when there is a small current at the base pin, a large current (or voltage) can pass through the transistor and into the LED or motor. It's probably a good idea to use transistors on a circuit with many LEDs even if only 1 or 2 are needed to be on at one time incase there is a bug in the circuit and they all accidentally turn on. More on transistors later.

To turn pins P1.0 and P1.6 on and off using code the first thing that needs to be done is to configure them as outputs and then give them a value:

P1DIR and P1OUT are defined in include/msp430/msp430x2xx.inc. They are hardware registers (not to be confused with CPU registers) that can be written to and read from like RAM, but changing their value will change the behavior of the MSP430's input / output pins. The hardware registers are used to configure the peripherals on the chip. The trick for digital I/O is to imagine the array of pins P1.7 to P1.0 as a binary number. In the above example:

So P1.6 and P1.0 in the P1DIR register have a value of 1 so they are configured as outputs. P1.6 is 1 and P1.0 is 0 so P1.6 (pin 14) is going to output 3.3v and P1.0 (pin 2) will output 0v. Because there are LEDs on those pins, when they are outputting 3.3v the LEDs turn on. Since the rest of the pins are configured as input, if the P1.1 pin (pin 3 on the MSP430G2553) is connected to 3.3v through a resistor (use 20k to 50k) a register P1IN will have a value:

The value can be easily read with code like:

Note that these digital I/O registers must be read / written to with 8 bit instructions.

Downloading Software

On Ubuntu mspdebug can be installed by using:

There are precompiled binaries for Windows and Mac for naken_asm and a tarball with source code, but really the best thing is to clone the repo. That can be done by executing the following commands from the terminal:

This will create binaries for naken_asm (the assembler) and naken_util which is a utility that can disassemble code and also contains a simulator for some CPUs, including the MSP430. This means an MSP430 program can be assembled with naken_asm and executed step by step in software with the ability to examine registers and memory and such.

The naken_asm repo also contains documentation and sample code.

Assembling and Running launchpad_blink.asm

In the samples directory of naken_asm is small program called launchpad_blink.asm. This program will blink the two LEDs in the circuit above, but would also blink the two LEDs on the Launchpad itself since they are connected to P1.0 and P1.6 also. To assemble it the following can be done:

There are some extra command line arguemnts there. The -o tells the assembler that the output filename should be called launchpad_blink.hex. Normally it would default to out.hex. The -l tells the assembler to generate a launchpad_blink.lst file which contains all of the source code from launchpad_blink.asm along with the opcode that got generated for each instruction plus how many CPU cycles that instruction would take to execute. The -I option tells what directory to look in to find any .include files.

To copy the .hex file from the computer to the MSP430 is done with mspdebug like so:

The above shows using the "prog" command to copy the program from the computer to the MSP430. The "run" command tells the MSP430 to start executing the code. Pressing ctrl-C will stop the program and dump the registers along with a disassembly of the currently executing instruction.

If the running program had code like this:

Some memory would be set in the MSP430:

In mspdebug the "md" command can be used to examine memory.

Launchpad Blink

The launchpad_blink.asm looks like this:

The first thing this program done is disables the watchdog timer. A watchdog timer is a counter that starts at 0xffff and decrements by 1 every clock cycle. If it ever reaches 0, the system will reset. So if the watchdog timer is running, the software will need to periodically set the timer back to 0xffff to make sure it doesn't reset. This can be useful if the system needs a fail-safe to recover from a crash. If the chip hangs and doesn't "kick the dog" the system can reset and hopefully recover. In this case (and in most cases) it's just annoying so it's turned off. Most systems don't enable the watchdog by default, but MSP430 seems to.

To create a delay loop between toggling the LEDs, a simple loop is created. The r9 register starts at a value of 60000 and decrements until it reaches 0. It takes 1 cycle to do the dec.w r9 and 2 cycles to jnz (jump if not zero) back to the dec.w instructions. So that delay will be 60,000 * 3 = 180,000 cycles. If the chip is running at 1MHz then it will blink 1,000,000 / 180,000 = 5.5 times a second.

Clock Sources

The clock source will define how many CPU cycles per second the chip will get for executing instructions (or running timers). The MSP430 can have multiple clock sources and run different peripherals with those different clock sources. For example a 32.768kHz crystal can be attached to the XIN/XOUT pins and one of the timers can be configured to use it, while another timer is configured to use the main system clock.

For these cheaper MSP430 chips, the system clock is probably going to be something called the DCO. The DCO is done with an internal resistor and capacitor I believe. It can be configured to run below 1MHz all the way up to above 16MHz, which will cause the chip to glitch all over the place. The DCO is also very inaccurate. Its heavily affected by temperature. It's really best not to run the chip above 8MHz and for most things 1MHz works great. Also, the slower the speed, the longer the battery will last if it runs on battery.

In order to set the DCO speed, there are two constants to use: DCO_x (DCO speed) and RSEL_x (range select):

To test the actual clock speed of the DCO on two different MSP430G2553 chips, I used a circuit that had a 32.768kHz crystal (a very very accurate clock source) setup with one the MSP430G2553's timers so it would trigger an interrupt once a second and count how many DCO cycles passed over that time. I ended up with these results:

Running the exact same firmware on another MSP430G2553 chip got these quite different results:

Timers

A typical peripheral in a microcontroller is a timer. The name is a little bit... awkward because it's technically more of a counter that can be used as a timer. There are two timer modules in the MSP430G2553 that can each be configured completely differently: each can use their own clock source, their own "max" value, count up/down, different compare / capture config, etc.

The code below is from a program that sets up two timers. The first timer uses the master clock (SMCLK) which is the DCO at 8MHz to count from 0 to 256. At another place in the code the P1.2 is setup so that when the timer starts at 0, the pin is high but when the timer reaches the value in the register TACCR1, the pin goes low.

The second timer is connected to a 32.768kHz crystal so that when it reaches a count of 4 it will trigger an interrupt. The interrupt reads a new value from an array of sound data and and changes TACCR1.

Analog to Digital converters (ADC)

Analog to digital converters are used to convert a voltage into a number. For example, if a pin is set up as an analog in pin and the reference voltage for the ADC is 3.3v, if it's a 10bit ADC module then the value will be 1023 * (Vin / Reference voltage). So if the voltage is 3.3v, the ADC's value will be 1023. If the voltage is 0, the ADC's value will be 0. if the voltage is 1.6v, the ADC's value will be 496.

A short example of using the ADC (and a timer interrupt) to read sound samples from a guitar is MSP430G2231 Guitar Processor

UART

UART is an aynchronous communication protocol. It's done by setting up a baud rate... how many bits per second that can be sent. If the baud rate is 9600 is 9600, then 9600 bits per second can be sent. The protocol is 10 bits wide, so really that means 960 bytes per second.

At 9600 baud, each bit is 1 / 9600 seconds (~0.1ms) per bit. The protocol requires 1 wire / pins per direction (a transmit wire TX and a receive wire RX). The protocol leaves a wire high when idle. To send a byte of data, the pin will go low for the length of 1 bit (start bit), and then for every 8 bits in the byte it will be high for a 1 or 0 for a 0. There is a stop bit at the end that holds the wire high for the length of a bit.

Setting up the MSP430G2553 UART in hardware looks like this:

Note that since the DCO is not accurately 2MHz, the divisor programmed into UCA0BR0 : UCA0BR1 isn't exactly 2,000,000 / 9600.

An example of using the UART is this Weather Station project.

SPI

SPI is a 4 wire protocol that consists of a chip select, clock, data in, and data out.

i2c

i2c is a communication protocol that uses just 2 wires: SDA / SCL. SDA will be a data pin that is switched from output mode to input mode depending on if the device needs to read from the bus or write to it. The SCL signal is a clock signal that only the master device has control of.

Using Transistors

Coming soon.

Copyright 1997-2024 - Michael Kohn