Hello Hack-A-Day and Dangerous Prototypes readers!  Please vote for me in the Sparkfun uC Contest!  (If you vote for me you can still vote for other projects as well)  The vote button is just up and left of here... there you go... closer... closer...  I know you can do it...

1.) I do, in fact, own an Arduino and despite this being a microcontroller project on Instructables, an Arduino is NOT a part of this guide. An Arduino has it's specific uses and fills a niche in my toolkit very well but Arduino is usually not my first choice when deciding which platform I'll prototype my latest idea with. One of the best parts of the Arduino platform is that it is streamlined to the point that anyone can use it without being an engineer. However, someone serious about the code they are writing for their project, will before long, need an essential feature: in-circuit debugging. We'll go over why ICD is so great and discuss how to use it as we build this simple project.

2.) What the heck is a Pomodoro timer, you ask? The Pomodoro technique is a means of time management created by Francesco Cirillo. You can find lots more information here: http://www.pomodorotechnique.com/ Personally, I love the Pomodoro technique but didn't want to run yet another application on my computer. Thus, I needed a simple timer. If you don't need or want a Pomodoro timer, the end result of this Instructable isn't as important as the means of getting to it and learning how to debug. What I really want to teach is some simple debugging concepts your average Arduino user may not know they are missing out on.

3.) This project is based around the Texas Instruments LaunchPad development board, an MSP430G2211 and five LEDs. If you don't have a Launchpad and have any interest in embedded programming at all, please just order one now. You can thank me later.

Take a look at the final step for the components needed for the pomodoro timer, if you're interested in making one.

4.) IAR Embedded Workbench Kickstart for MSP430 is the development environment we'll be using. Download it from here: http://www.ti.com/iarkickstart This is unfortunately a Windows-only IDE, but it runs in various virtual machines on both Linux and OS X. For this Instructable, I'm using Parallels on OS X. If there is sufficient interest, I'll write a guide for MSP430 development using FOSS tools on OS X.


Step 1: Putting the Prototype Board Together

Got all of the parts? Good. Let's throw this thing together real fast. First, DISCONNECT the Launchpad from your computer if it is connected. The Launchpad should NOT have power.

Remove the TXD, RXD, and P1.6 jumpers from the board. Put the microcontroller in the Launchpad if you haven't already. The groove in the microcontroller goes towards the USB connector.

LEDs don't work if put in backwards so pay attention to their polarity. Here is a quick primer if needed: http://www.sparkfun.com/tutorials/222. Thanks Sparkfun!

For all five LEDs, bend the cathode straight out. (That's the short leg). Put the LEDs, 100ohm resistor, and paperclip together like they are in the picture. I'd prefer a bit solder to the paperclip, but we're keeping things as simple as possible.

The LEDs, one each, are in ports P1.1 – P1.5.  The paperclip prototyping method seen below works in lieu of solder.  The 100 ohm resister completes the LED's path to GND.

My piezo speaker was a lucky find as it already had a .1” pitch header on it. It that is the case, you can remove the P1.6 jumper and attach the speaker directly to the board. Otherwise, you need to make a connection from P1.6 through the speaker to GND.

For those that want to make this a stand-alone device, the final schematic is included in this guide on the last page. 

Step 2: Setting Up the Project

Now, let's start talking to the MSP430.

Launch IAR Embedded Workbench.

From the menu, select “Project” → “Create New Project...

Make sure the Toolchain is “MSP430” and select “main” from under the “C” option. (See image 1)

Save the project as “pomodoro” when prompted.

Go to the “Project” menu and select “Options”. Under “General Options” make sure the target is “MSP430G2211”. Under “Debugger” the “Driver” option should be “FET Debugger”. All other options should remain at their defaults. Close the options dialog. (images 2 & 3)

A template main.c should be open. We're going to replace it with our own code from below: 

#include "msp430g2211.h"

#define LED4 BIT1
#define LED3 BIT2
#define LED2 BIT3
#define LED1 BIT4
#define LED0 BIT5
#define BUZZER BIT6

void main( void ) {

   // Stop watchdog timer to prevent time out reset
  // Set DCO to 1MHz factory calibration value
  BCSCTL1 = CALBC1_1MHZ;    

  //all LED pins and buzzer as output
  P1DIR |= (LED0 + LED1 + LED2 + LED3 + LED4 + BUZZER); 

  while(1) { //loop forever
    //all LED pins and buzzer on
    P1OUT |= (LED0 + LED1 + LED2 + LED3 + LED4 + BUZZER); 
    //all LEDs and buzzer off
    P1OUT &= ~(LED0 + LED1 + LED2 + LED3 + LED4 + BUZZER);

From the menu, select “Project” → “Compile”. If prompted to save your workspace, you can give it the same name as the project, i.e. “pomodoro”.

As long as there were no problems compiling your project, you should be able to upload to the board. To do this select from the menu “Project” → “Download and Debug...” 

Step 3: Debugging: First Steps

I quick glace at the code and you could guess that this program is going to flash all of the LEDs on and off over and over again forever. In fact, it should do it about 500,000 times a second.

So why isn't anything happening? (You should have a green line of code as in image 1).

Here's what's going on. The compiled code was uploaded to the microcontroller and the microcontroller has started to execute that code. However, it has paused at the first instruction. The green arrow and green line of code indicate the execution is paused at line 13.

Press the “Step Into” button () four times and watch as the code execution advances. It should have stopped on line 20, which tells the microcontroller to turn on all the LEDs. Why aren't the LEDs on? While using the debugger, the green arrow and line of code indicates which line of code is about to be executed. It has not happened it. Press “Step Into” () once more .

Now is a good time to check your LEDs. All five should be illuminated. Make sure all your connections are good, that the LEDs are lit, and press “Step Into” () again. Obviously, all the LEDs should be off now.

Click the “Go” () button. The microcontroller is now running is if you were not debugging it. Instructions are flying by, one million per second, and the the LEDs are toggling half that fast. Thus, they look half as bright as they did when halted in the debug session.

To verify the dimming effect, hit the “Break” () button. There is a fifty/fifty chance it will stop with the LEDs lit. If they aren't, go ahead and press “Step Into” () until they are. 

Step 4: Adding Bugs!

Let's now add the rest of the bugs.... err.. code. This code was written with an intentional bug but should compile just fine. Upload it to the microcontroller and start a debugging session.

#include "msp430g2211.h"

#define LED4 BIT1
#define LED3 BIT2
#define LED2 BIT3
#define LED1 BIT4
#define LED0 BIT5
#define BUZZER BIT6

unsigned int clicks = 0; //counter for each timer irq
unsigned int seconds = 0; //counter for seconds
unsigned int minutes = 0; //counter for minutes
unsigned int new_minute = 0; //marker for reaching the next minute

//configurable options!
const unsigned int pomodoro_length = 25; //how long should the pomodoro be? [default: 25]
const unsigned int pomodoro_break = 5; //and the break? [default: 5]

//sets the LEDs to reflect the low 5 bits of 'value'
void setLEDs (char value) {
  if(value & 0x10)
    P1OUT |= (LED4); // set LED4 on
    P1OUT &= ~(LED4); //set LED4 off

  if(value & 0x08)
    P1OUT |= (LED3); // set LED3 on
    P1OUT &= ~(LED3); //set LED3 off

  if(value & 0x04)
    P1OUT |= (LED2); // set LED2 on
    P1OUT &= ~(LED2); //set LED2 off

  if(value & 0x02)
    P1OUT |= (LED1); // set LED1 on
    P1OUT &= ~(LED1); //set LED1 off

  if(value & 0x01)
    P1OUT &= ~(LED0); // set LED0 on
    P1OUT |= (LED0); //set LED0 off

void main( void ) {

  unsigned int pomodoro_remain = pomodoro_length + pomodoro_break; //counter to keep track of time passed

  WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer to prevent time out reset
  BCSCTL1 = CALBC1_1MHZ; // Set DCO to 1MHz factory calibration value

  CCTL0 = CCIE; // CCR0 interrupt enabled
  CCR0 = 50000; // timer irq rate
  TACTL = TASSEL_2 + MC_1; // SMCLK, upmode
  _BIS_SR(GIE); // enable interrupt

  P1DIR |= (LED0 + LED1 + LED2 + LED3 + LED4 + BUZZER); //all LED pins and buzzer as output
  P1OUT &= ~(LED0 + LED1 + LED2 + LED3 + LED4 + BUZZER); //all LEDs and buzzer off

  while(pomodoro_remain) { //let's run this loop until the pomodoro is done
    if(minutes > new_minute) { //see if we have reached the next minute
      setLEDs(pomodoro_remain); //set the LEDs to reflect the current minute
      new_minute = minutes; //change our counter
      pomodoro_remain--; //less time remains in our pomodoro
  while(1){} //this is the song that never ends, some people started singing it...

// Timer A0 interrupt service routine
// This runs when a timer interrupt is triggered
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void) {

  clicks++; // new click every 1Mhz/50k = 20 times a seconds
  if (clicks >= 2) { //we're using the number 2 here instead of 20 to
                     //speed up debugging
// if (clicks >= 20) { //waited a full second yet?
    clicks = 0; //then reset the counter..
    seconds++; //advance second counter
    if(seconds >= 60) { //see if we have waited a minute?
      seconds = 0; //then reset second counter
      minutes++; //advance minute counter

Step 5: Breakpoints, Locals, and Registers

Hit the “Go” () button to start the pomodoro. Pay close attention to the LEDs. There is something fishy about the values they show. When the timer first starts, it should show the total number of pomodoro minutes (25) plus the break minutes (5). In binary, that's '11110'. Hmm... why are all five LEDs on?

So, let's take a look at the 'setLEDs' function. Either it is receiving the wrong value or receiving the right value but displaying the wrong value (or some strange combination of both).

Scroll down to the first line of the setLEDs function (line 22, see image 1). Right-click any part of that line and select "Toggle Breakpoint (Code)". Notice the red dot to the left of that line of code? You can double click in that margin to set/unset breakpoints as well. (image 2) A breakpoint is a point the in the code where program execution will break allowing you to debug.

With the breakpoint set, press the "Reset" () button. After pressing "Reset" you'll be prompted with a long winded message that says it may take a long time to 'Run to main'. What this means is that your debugger is set to stop at the first line in the main function but your only hardware breakpoint is set at line 22. In order to stop at main, the program will execute one line at a time until it gets to main. Right now, that isn't a big problem, but this limitation can be troublesome with more complicated code. Note that more capable microcontrollers can allow many more hardware breakpoints, but one is better than nothing (yes, I'm look at you Arduino). :)

For now, just understand, that if a breakpoint is set when you start your code, it'll take an extra second or two to reach main.

Whew.. okay. The green arrow is at the first line in main now (line 50, see image 3)? Great, now we could single step (i.e. "Step Into" ()) all the way to the setLEDs function, but this could take a very long time. Instead, because we have a breakpoint, we just hit "Go" ().

Almost immediately, the green arrow scrolls to line 22. To get a better idea about what this function is doing, select “View” → “Locals” from the menu. (image 4) In the window that comes up, the local variable “value” is displayed with... err.. it's value, “0x1e”. Right-clicking on the variable in the locals window lets you change the base notation of the value. Change it to decimal and notice now that the function did indeed get passed the correct number (30).

Since this function only deals with a single variable and we know it is correct, let's close the “Locals” window. Now select “View” → “Register” from the menu. In the “Register” window, change the dropdown box to show “Port 1/2”. Expand the “P1OUT” tree. (image 5)

P.0 and P.7 may have random values but P.1 – P.6 should all be zero. Press “Step Into” () a few times. As we single step through the code, we can watch the registers change. You don't even need to look at the datasheet to know that the P1OUT register is the state of the digital pins on the microcontroller since the LEDs should be reflecting what you see in the “Register” window. Red values in the “Register” window mean that the last instruction executed changed that particular value. This applies to variables in the “Locals” window as well.

Note that the value only turns red if the register changes, so after executing line 45, the register is red and is showing a 1 instead of the expected 0. We found our bug! Looks like I reversed the binary operators. (image 6)

Step 6: On-the-fly Memory Changes!

While we're still debugging, there is one more very interesting feature I'd like to point out. Close the “Register” window if you still have it open. From the menu select “View” → “Memory”. Initially, it doesn't look like much, but this is the state the actual on-board memory. In the “Go to” box, type “minutes”. This should highlight two bytes. (image 1) These are the two bytes that store the value for the current number of minutes that this pomodoro timer has been running.

The absolute best part of this? You can change memory on the fly simply by typing in the memory window! This is a fantastic feature, but this can really mess things up as well, so be careful (or at least ready to reboot the microcontroller). On-the-fly memory changes also apply to registers and variables in the locals window.  Simply double-click the current values to change them to what you want to try!

Now that is cool, huh?  Can your Arduino... nevermind.

I'm sorry Arduino, I really do think you're great... but In-Circuit Debugging is awesome!

Step 7: IAR Debug Menu Options

Below are descriptions of all the debug toolbar buttons in IAR Embedded Workbench.  Most microcontroller IDEs with debugging interfaces, (AVR Studio, MPLAB, etc...) have similarly named functions so this should serve as a general reference.

Command Icon Description
Go Executes from the current statement or instruction until a breakpoint or program exit is reached.
Break Stops the application execution.
Reset Resets the target processor.
Stop Debugging Stops the debugging session and returns you to the project manager.
Step Over Executes the next statement, function call, or instruction, without entering C or C++ functions or assembler subroutines.
Step Into Executes the next statement or instruction, entering C or C++ functions or assembler subroutines.
Step Out Executes from the current statement up to the statement after the call to the current function.
Next Statement Executes directly to the next statement without stopping at individual function calls.
Run to Cursor Executes from the current statement or instruction up to a selected statement or instruction.

Step 8: Super Plumber Pomodoro Timer

To make the finished product, in addition to the MSP430 and LEDs, you'll also need a piezo speaker/buzzer, a 3v battery, a 10k resistor, three 100 ohm resisters, a NPN & PNP transistor, and a switch. You can probably scavenge most of the parts from old/broken electronics or for less than a six-pack of good beer you can order everything, including the Launchpad from Digikey or Mouser.

Piezo speaker/buzzers can be found in most anything that makes sound. The one I'm using is from an old fax machine. The 3 volt battery can be a coin cell battery or two AA or AAA batteries in series.  I used a 20mm coin battery holder only to realize later that I was out of 20mm coin batteries.  The LEDs are scavenged right angle bulbs that have sat in my junk box for years.

The final schematic is below and should be fairly straight forward so I won't go into exact point A to point B connections.

Note the polarity on your batteries and LEDs.  Doesn't matter for the speaker and resistors.  

I didn't use a bypass capacitor or any of the resistors except R1 on my final version but included them in the schematic.  If you're build isn't working correctly, adding C1 first and then the resistors may help.

Note that timing 30 minutes with an internally clocked uC is not the best practice.  My final version actually takes 30:30 to run the entire pomodoro and would of course be temperature dependent.

As for the name "Super Plumber Pomodoro Timer", just watch the video :)  This isn't recorded audio (as there would be no room for it) but generated by a piano note -> hertz lookup table.  Thanks to youtube user ech0sdev for his MSP430 implementation that I stole and expanded ( http://www.youtube.com/watch?v=oEx_EgIlvtc ).  Note that I believe his timing values are possibly for 8mhz (he said he wasn't clear about the timing) while mine are for 1mhz.

The madness with the transistors may not be clear, but it is a fun little mini circuit to breadboard if you want to play with it.  It allows the MSP430 to kill it's own power.

Thank you all for reading this!  The pomodoro timer is a little quick and dirty (power consumption could be MUCH improved) but hopefully you may have learned something about the power of In-Circuit Debugging.

Step 9: Super Plumber Pomodoro Timer Code!


#include "msp430g2211.h"
#include "notes.h"

unsigned int clicks = 0;
unsigned int seconds = 0;
unsigned int minutes = 0;
unsigned int new_minute = 0;
const unsigned int pomodoro_length = 25;
const unsigned int pomodoro_break = 5;

#define LED4 BIT1
#define LED3 BIT2
#define LED2 BIT3
#define LED1 BIT4
#define LED0 BIT5
#define BUZZER BIT6
#define POWER BIT7

void setLEDs (char value) {
  if(value & 0x10)
    P1OUT |= (LED4); // set LED4 on
    P1OUT &= ~(LED4); //set LED4 off

  if(value & 0x08)
    P1OUT |= (LED3); // set LED3 on
    P1OUT &= ~(LED3); //set LED3 off

  if(value & 0x04)
    P1OUT |= (LED2); // set LED2 on
    P1OUT &= ~(LED2); //set LED2 off

  if(value & 0x02)
    P1OUT |= (LED1); // set LED1 on
    P1OUT &= ~(LED1); //set LED1 off

  if(value & 0x01)
    P1OUT |= (LED0); // set LED0 on
    P1OUT &= ~(LED0); //set LED0 off

void main( void ) {

  unsigned int pomodoro_remain = pomodoro_length + pomodoro_break;

  WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer to prevent time out reset

  BCSCTL1 = CALBC1_1MHZ; // Set DCO to 1MHz factory calibration value

  P1DIR |= (LED0 + LED1 + LED2 + LED3 + LED4 + BUZZER + POWER); //all LED pins and buzzer as output
  P1DIR |= POWER; //POWER remains on until we want to kill our own power
  P1OUT &= ~(LED0 + LED1 + LED2 + LED3 + LED4 + BUZZER); //all LEDs and buzzer off

  CCTL0 = CCIE; // CCR0 interrupt enabled
  CCR0 = 50000; // clock divisor
  TACTL = TASSEL_2 + MC_1; // SMCLK, upmode
  _BIS_SR(GIE); // enable interrupt


  while(pomodoro_remain) {
    if(minutes > new_minute) {
        new_minute = minutes;
        if(pomodoro_remain == pomodoro_break) {
        } else {
            beep(G2, 124); // .25 beep, except when we reach the break

  play1up(); //final chime
  P1OUT &= ~(POWER); //set POWER off
  // Sleep forever... shouldn't reach this, but who knows? :)
  _BIS_SR(LPM1_bits + GIE);


// Timer A0 interrupt service routine
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void)
  // we will get called at 1Mhz/50k = 20 times a seconds
  if (clicks >= 20) {
    clicks = 0;
    seconds++; // advance clock for each second
      if(seconds >= 60) {
        seconds = 0;


//this shouldn't be here, but I was in a hurry to submit
//before the contest deadline ran out :)
#define BUZZER BIT6

//Definition of the notes' frequecies in Hertz.
#define C8 4186
#define B7 3951
#define As7 3729
#define A7 3520
#define Gs7 3322
#define G7 3136
#define Fs7 2960
#define F7 2794
#define E7 2637
#define Ds7 2489
#define D7 2349
#define Cs7 2217
#define C7 2093
#define B6 1976
#define As6 1865
#define A6 1760
#define Gs6 1661
#define G6 1568
#define Fs6 1480
#define F6 1397
#define E6 1319
#define Ds6 1245
#define D6 1175
#define Cs6 1109
#define C6 1047
#define B5 988
#define As5 932
#define A5 880
#define Gs5 831
#define G5 784
#define Fs5 740
#define F5 698
#define E5 659
#define Ds5 622
#define D5 587
#define Cs5 554
#define C5 523
#define B4 494
#define As4 466
#define A4 440
#define Gs4 415
#define G4 392
#define Fs4 370
#define F4 349
#define E4 330
#define Ds4 311
#define D4 294
#define Cs4 277
#define C4 262
#define B3 247
#define As3 233
#define A3 220
#define Gs3 208
#define G3 196
#define Fs3 185
#define F3 175
#define E3 165
#define Ds3 156
#define D3 147
#define Cs3 139
#define C3 131
#define B2 123
#define As2 117
#define A2 110
#define Gs2 104
#define G2 98
#define Fs2 92
#define F2 87
#define E2 82
#define Ds2 78
#define D2 73
#define Cs2 69
#define C2 65
#define B1 62
#define As1 58
#define A1 55
#define Gs1 52
#define G1 49
#define Fs1 46
#define F1 44
#define E1 41
#define Ds1 39
#define D1 37
#define Cs1 35
#define C1 33
#define B0 31
#define As0 29
#define A0 28

void delay_ms(unsigned int ms ) {
    unsigned int i;
    for (i = 0; i<= ms; i++)

void delay_us(unsigned int us ) {
    unsigned int i;
    for (i = 0; i<= us; i++)

//This function generates the square wave that makes the piezo speaker sound at a determinated frequency.
void beep(unsigned int note, long duration) {

    long delay = (long)(62500/note); //This is the semiperiod of each note.
    long time = (long)((duration*100)/delay); //This is how much time we need to spend on the note.

    for (long i = 0; i < time; i++) {
        P1OUT |= BUZZER; //Set buzzer on...
        delay_us(delay); //...for a semiperiod...
        P1OUT &= ~BUZZER; //...then reset it...
        delay_us(delay); //...for the other semiperiod.

void playTheme(void) {
  beep(E4, 124); beep(E4, 124); delay_ms(124);
  beep(E4, 124); delay_ms(124);
  beep(C4, 124); beep(E4, 124); delay_ms(124);
  beep(G4, 124); delay_ms(496);
  beep(G3, 124); delay_ms(496);
  beep(C4, 124); delay_ms(248);
  beep(G3, 124); delay_ms(248);
  beep(E3, 124); delay_ms(248);
  beep(A3, 124); delay_ms(124);
  beep(B3, 124); delay_ms(124);
  beep(As3, 124); beep(A3, 124); delay_ms(124);
  beep(G3, 124); beep(E4, 124); delay_ms(124);
  beep(G4, 124); beep(A4, 124); delay_ms(124);
  beep(F4, 124); beep(G4, 124); delay_ms(124);
  beep(E4, 124); delay_ms(124);
// beep(C4, 124); beep(D4, 124); beep(B4, 124);
// sounds better without the last line unless looped

void play1up(void) {
//1up sound
  beep(E5, 62); delay_ms(62);
  beep(G5, 62); delay_ms(62);
  beep(E6, 62); delay_ms(62);
  beep(C6, 62); delay_ms(62);
  beep(D6, 62); delay_ms(62);
  beep(G6, 312);

void playFlagTune (void) {
  beep(G2, 124);
  beep(C3, 124);
  beep(E3, 124);
  beep(G3, 124);
  beep(C4, 124);
  beep(E4, 124);
  beep(G4, 372);
  beep(E4, 372);

  beep(Gs2, 124);
  beep(C3, 124);
  beep(Ds3, 124);
  beep(Gs3, 124);
  beep(C4, 124);
  beep(Ds4, 124);
  beep(Gs4, 372);
  beep(Ds4, 372);

  beep(As2, 124);
  beep(D3, 124);
  beep(F3, 124);
  beep(As3, 124);
  beep(D4, 124);
  beep(F4, 124);
  beep(As4, 372);
  beep(As4, 124);
  beep(As4, 124);
  beep(As4, 124);
  beep(E4, 372);

I'd like to thank you for this example code - had a hard time understanding how to use timers and this definitely helped a lot (don't care a bit for the pomodoro, just the example of how to make a proper Timer interrupt). :)
After I learned my C bitwise operators and figured out that you were using the Hex numbers to filter bits, I found the error before I read about it in step 5! Thanks for the great intro to debugging, and for making it just complex enough that I had to learn something new!<br><br>It's probably absurd that I understand all that without knowing any programing languages. Time to learn C! :)
In Step 2, the line &quot;WDTCTL = WDTPW + WDTHOLD;&quot; is in your comment.<br>Looking at the screenshot in Step 3, you did not intend this.<br>I though it was an intentional bug at first, until I kept reading. <br><br>In the meantime, I am still trying your example. I am not familiar with C, MSP430s, IAR, or really any of it. I understand the basics of programing and circuits, but despite having compiled and downloaded the code, all I have managed to do is get the P1.3 LED to glow dimly and continuously. The other LEDs and buzzer show no signs of anything. I have tested the LEDs through the paperclip junction (alligator clip on mine) for continuity, and the joint is good. I have rearranged the LEDs and moved the buzzer between the two acceptable location to no avail. I haven't noticed any magic smoke. Do you have any ideas for what I could be doing wrong and/or how to correct it?
Excellent! I believe mouritsen is having the same problem. If you go to &quot;Download and Debug&quot; and it finished instantly, you're probably still using the simulator. It takes a few seconds to program the actual microcontroller.
Thanks for the heads up about the bug on page 2. You definitely need to include the WDTCTL line. Should be fixed now.<br><br>As for getting the LEDs to turn on, try stopping execution after this line:<br><br>P1OUT |= (LED0 + LED1 + LED2 + LED3 + LED4 + BUZZER);<br><br>At that point, you should have 5v coming from P1.1-5. It may be best to test each point individually with a multimeter or move the LED-&gt;alligator/paperclip-&gt;resistor bridge to each point. There isn't really any need to test the buzzer at that point.
You're welcome. It is correct above, now.<br><br>I tried your suggestion, and I am getting 1.6V on P1.3, independently of wherever I stop it. No other pin is supplying voltage. I think I must have a download error, or a dead chip. I'll have to find a way to test that, I guess.
While the code is running, the LED ports will be cycled on and off very quickly. So quickly in fact that a multimeter will show half of the &quot;on&quot; voltage (3.3v * 0.5 = 1.6V). [*** Note my above comment says 5v where it should be 3.3v. ***]<br><br>
I meant to say &quot;I noticed that you have not soldered the included crystal to the pads, whereas I have.&quot;
My project relies on the internal oscillator. Using the external osc would likely make for a bit more accurate timer, if you intend to take the project that far, but simply soldering it to the board isn't enough to cause the microcontroller to use it. There are fuse bits that need to be set. Don't worry about that for now. Trying running this:<br> <br> <table bgcolor="#ffffff" border="1"> <tbody> <tr> <td> <font face="courier">#include &quot;msp430g2211.h&quot;<br> #define LED4 BIT1<br> #define LED3 BIT2<br> #define LED2 BIT3<br> #define LED1 BIT4<br> #define LED0 BIT5<br> #define BUZZER BIT6<br> <br> void main( void ) {<br> <br> // Stop watchdog timer to prevent time out reset<br> WDTCTL = WDTPW + WDTHOLD;<br> // Set DCO to 1MHz factory calibration value<br> BCSCTL1 = CALBC1_1MHZ;<br> DCOCTL = CALDCO_1MHZ;<br> <br> //all LED pins and buzzer as output<br> P1DIR |= (LED0 + LED1 + LED2 + LED3 + LED4 + BUZZER);<br> <br> P1OUT |= LED0;<br> P1OUT &amp;= ~LED0;<br> P1OUT |= LED1;<br> P1OUT &amp;= ~LED1;<br> P1OUT |= LED2;<br> P1OUT &amp;= ~LED2;<br> P1OUT |= LED3;<br> P1OUT &amp;= ~LED3;<br> P1OUT |= LED4;<br> P1OUT &amp;= ~LED4;<br> <br> while(1){} //do nothing forever... </font></td> </tr> </tbody> </table> <br> Step through all the P1OUT lines individually to make sure they are turning the correct pin on and off.
Problem solved!<br><br>I noticed my error while setting up a Workspace for your test code. It turns out that my problem was scrolling my mouse wheel after selecting &quot;FET Debugger&quot; under &quot;Driver,&quot; so that I had inadvertently been working under &quot;Simulator.&quot; I ran your &quot;helloworld&quot; to confirm that my hardware worked, and then re-ran your Step 2 code.
Thanks, that explains the voltage difference! I guess the issue now is why P1.1, P1.2, P1.4, and P1.5 don't want to cooperate... I noticed that you have not soldered the included crystal to the pads. Could that explain my discrepancy?<br><br>I guess I will just have to try a hello world to each of the pins tomorrow to see if I can isolate the problem.
I get the exact same result as NewB0007. P1.3 LED glows dimly and no other LEDs ever light up. I noticed if I press S2 then P1.3 LED turns off until I release S2. Also LED1 and LED2 continuously flip on and off back and forth as in red-green-red-green, etc. If I unplug the USB cable and disconnect the LEDs and 100 Ohm resistor the default temperature program still works. I don't think my code is being written to the chip. Any suggestions? This is my first project since my 430 came in the mail today, so maybe there is some kind of initial setup I need to do either in IAR or something else? Any help would be great. Thanks for the tutorial. I'm looking forward to learning how to use this thing.
&quot;If there is sufficient interest, I'll write a guide for MSP430 development using FOSS tools on OS X.&quot;<br><br>+1 for interest on this topic! I just got a couple Launchpads for my first ever foray into uC programming and I'll soon be getting an OS X machine. Being able to use those together would be awesome.
Vote for me in the Sparkfun Microcontroller contest and the odds of me writing a MSP430 in OS X guide will grow exponentially :)<br><br>Seriously, though, I think that'll be my next Instructable.<br><br>PS... seriously, though, vote for me!
I just want to point out that you shouldn't connect a lot of LEDs with only one resistor. Although you might think that the current flow is evenly distributed through all the LEDs, they are not, one might have more current flowing through it than the others due to very slight differences in conductance. For the purposes here, it's not a big deal, just a bad habit.<br><br>Also just a reminder for everybody, two diodes rated at 1A each placed in parallel does NOT mean you can let 2A through, unless the diodes are absolutely identical, which is almost impossible in the real world. One will let more current flow through than the other, and that one gets warmer, and actually increases its conductance.
Don't forget that he probably set the resistor like waaaaay above the limit to make sure that erven with 5 leds on,the current won't kill it. I'm pretty sure you didn't think about that ;)
To be perfectly honest I didn't calculate how much the output pins are sourcing because I didn't recommend a specific LED for the project. While I could calculate what I'm using, it wouldn't be the same for others anyway. <br><br>Debugging, not the circuit, is the emphasis of the tutorial. From personal experience, MSP430G2xxx's are able to both sink and source much more than the datasheet specifies so I felt comfortable with extremely easy solution.<br><br>That obviously shouldn't be relied on for a critical project but for this purpose, the single GND port can be used for the sake of convenience.

About This Instructable




More by kphlight:Intro to Microcontroller Debugging (and a Pomodoro Timer) 
Add instructable to: