msp430afe253 uart sample code

What development kit are you using?

If you are using the MSP430AFE2xx 16 Bit Microcontroller 24-Pin Socket Target Board (MSP-TS430PW24), it does not have an on-board RS-232 transceiver to translate the signaling from a PC COM port to the USART.  I am assuming your statement about "that are converter then to pin 20" means you have added an external transceiver.

Have you observed via an oscilloscope the data sent from the PC to the URXD0 on the MSP430 side of the RS-232 transceiver?

Is your breakpoint ever reached?

Is the baudrate on the PC consistent with what is expected by the example code?

The dev kit is the MSP-FET430U24.

I am using a RS232 transceiver and can see the data sent from the PC using an oscilloscope.  I sending characters at 115k baud.  I have used this same transceiver to talk to other msps in the past.

The break point is never reached inside the interrupt.  I can trigger one in the setup portion of the code.

I have narrowed it down a bit.  If I load code and power the board with an external power supply it works.  I powered it with 3.3V.  I am able to send characters and receive them back.

When I power the board using the fet tool and run the debugger I do not receive returned characters.  The fet tool is providing 2.66V

Glenn Brown said:

The fet tool is providing 2.66V

2.66V is a rather strange value for the FET, the preset value in CCS is 3V - but I don't know about other IDEs. Have you checked the current which is drawn by the experimenter board? Maybe you are just a bit above the limits for the FET (100mA) and so the voltage breaks down to 2.66V and that is like Jens pointed out most likely not enough for the RS232 (can you check the levels of the RS232 data lines with an oscilloscope?)

You are correct the value was 3V.  I altered to 3.3V in CCS to match the RS232 converter.  The voltage on the oscope for the RX line is normally at 3.4V and goes down to 0V when a character is sent.

I have not checked the current draw.  The only thing I have on the board is the msp.  The rs232 converter is powered from the usb of the pc.

Glenn Brown said:

The rs232 converter is powered from the usb of the pc.

It is a USB to 232 converter, so it provides. 3.3v  logic.  I have used it with other MSPs in the past with no issues.  This is the device: http://www.sparkfun.com/products/718

Glenn Brown said:

It is a USB to 232 converter, so it provides. 3.3v  logic.

Well, if you say that the (not-RS232-)converter worked with other MSPs, then this is most likely not the problem.
However, I don't see any other problem right now. Maybe it's int eh software, but I cannto tell. Because I don't know the code. Because you didn't post anything. ;)

I am just using a TI example:

MSP430AFE_uart_115k.c

//******************************************************************************
//   MSP430AFE25x Demo - USART0, 115200 UART Echo ISR, DCO SMCLK
//
//   Description: Echo a received character, RX ISR used. Normal mode is LPM0.
//   USART0 RX interrupt triggers TX Echo.
//   Baud rate divider with 1.1Mhz = 1.1MHz/115200 = ~10 (00Ah|0h)
//   MCLK = SMCLK = default DCO 
//
//                MSP430AFE25x
//             -----------------
//         /|\|              XIN|-
//          | |                 |
//          --|RST          XOUT|-
//            |                 |
//            |       P1.3/UTXD0|------------>
//            |                 | 115200 - 8N1
//            |       P1.4/URXD0|<------------
//
//  Naveen Kala
//  Texas Instruments, Inc
//  March 2011
//  Built with IAR Embedded Workbench Version: 5.20.1
//******************************************************************************
#include "msp430afe253.h"

void main(void)
{
  volatile unsigned int i;

  WDTCTL = WDTPW + WDTHOLD;                 // Stop WDT
  P1SEL |= BIT3+BIT4;                       // P1.3,1.4 = USART0 TXD/RXD
  do
  {
      IFG1 &= ~OFIFG;                       // Clear OSCFault flag
      for (i = 0x47FF; i > 0; i--);         // Time for flag to set
  }
  while ((IFG1 & OFIFG));                   // OSCFault flag still set?

  ME1 |= UTXE0 + URXE0;                     // Enable USART0 TXD/RXD
  U0CTL |= CHAR;                            // 8-bit character
  U0TCTL |= SSEL1;                          // UCLK= SMCLK
  U0BR0 = 10;                               // 1MHz 115200
  U0BR1 = 0x00;                             // 1MHz 115200
  U0MCTL = 0x00;                            // 1MHz 115200 modulation
  U0CTL &= ~SWRST;                          // Initialize USART state machine
  IE1 |= URXIE0;                            // Enable USART0 RX interrupt
  P1SEL2 |= BIT0;                           // Set SMCLK at P1.0
 
  _BIS_SR(LPM0_bits + GIE);                 // Enter LPM0 w/ interrupt
}

#pragma vector=USART0RX_VECTOR
__interrupt void USART0_RX (void)
{
  while (!(IFG1 & UTXIFG0));                // USART0 TX buffer ready?
  TXBUF0 = RXBUF0;                          // RXBUF0 to TXBUF0
}

Let me restate.  This code works fine when I power the device with a power supply.  It does not run when I use CCS and run the debugger..

Are you able to actually connect to the target, download the code and single-step through it?

The reason I ask is that the jumper JP1 needs to be switched when powering the board from the MSP-FET430UIF tool.

I presume that with the external power supply used, the JP1 jumper is on pins 2 and 3, correct?

Yes, I do connect with the target and load code.  I do switch the j1 depending on how I am powering the board.  I am able to breakpoint on setup lines of code.  I have tried placing a breakpoint inside the interrupt, but it never triggers when I send a character.

what PC application are you using? Is it hyperterminal or something similar?

I havn't used hyperterminal in a while, but I believe there is an option to echo in hyperterminal itself. 

I guess what I am trying to ask you is how do you know if the echo is happening at the PC application level or if it is happening through your board.

Of course one way is to make sure you turn off the echo option in whatever application your using.

Another way is toggle an LED in ur dev board whenever an echo occurs, just to make sure your code is working fine.

If you can toggle your LED, the next thing you can do is write a simple timer routine (so you avoid any external factors like the PC or the RS 232, and just work from within the MCU) and see if you can break inside the timer interrupt. Again, check the validity of the timer using a scope or and LED.

The timer test might be able to tell you if it is a compiler setup mistake or not. 

I know this is a round about way, but I can't think of anything else.

I am using a program called Docklight.  It species whether characters are sent or received.  When running MSP430AFE_uart_115k.c using an external power supply I get returned characters.  When running it using CCS 5.1 and the debugger I do not get the returned character.  This is the first project I have developed using CCS 5.1 on a windows 7 machine.  All my previous projects have been on a windows xp machine with ccs 3 and ccs 4.

I have been able to run a hello world blinky led kind of program.  I have not been able to use the uart with ccs and the debugger.

Ok. I didn't mean hello world led blink, I mean, insert an led toggle inside of your interrupt so you can see the LED go on and off, or just toggle a pin, and monitor the pin on the scope.

This is just a "sanity check".

So, if you enter debug mode using CCS 5.1, when you pause the code, you should be in line _BIS_SR(LPM0_bits + GIE);                 // Enter LPM0 w/ interrupt

Is that happening?

The code assumes the DCO running at a certain frequency, but it's not using a calibrated value. I've not tested that, but it might be that the debugger has some influence on the DCO in uncalibrated mode. So can you check if the DCO is running indeed at the 1MHz assumed by the program? (put it on a port pin)

Or you could try to use a calibrated DCO value (the USART configuration must change of course according to the new frequency).

Also you could try to just send some character (0x55 = U) from the MSP to the computer - if you receive garbage then it's most likely because the DCO frequency is not what it's expected to be. 

I tried setting up the DCO to a known frequency and also just sending a character on startup and no luck.

I have been using ccs5.1 and windows 7.

I went back to my old machine using windows xp and ccs4.2.

I created a project and put the original file MSP430AFE_uart_115k.c in the project and it works great in the debugger.  I send a character and it is returned.  I can breakpoint in the isr. I am going to develop on the old machine and worry about what the differences may be later.

Hi Glen,

I noticed a similar issue when trying to debug the MSP430AFE253 in CCSv5.1

You'll notice that the timer interrupt does not trigger either, but port interrupts do. It appears the debugger stops SMCLK and does not start it again. This version of CCS is using the newer MSP430.dll (version 3.2.1.009) and it is possible the bug lies there. For this version of the driver, there is a note in the revision file stating:

|    -    Clock Control not fully functional for AFE devices. 
|        Workaround: None.   

So I'd stick to CCSv4.2 until this is resolved.

Cheers,
Brett