MSP430FG4618/F2013 Experimenter's Board RS-232 Issue

Josiah Yeagley

Other Parts Discussed in Thread: MSP430FG4618

I am new to the MSP430 and to TI products in general and am trying to familiarize myself with them so I can make a proper evaluation on the practicality of their use in the company I work for's products. As stated in the subject I have a MSP430FG4618/F2013 Experimenter's Board and am trying to interface it with a PC using the DB 9 connector and RS-232. I have a cable connected to the DB 9 connector going to a UART to USB bridge that I have used for such a purpose on many an occasion. My problem is that I have been unable to get this working in any way. I will detail what I have done in an attempt to get this working and hopefully someone will be able to discern what I am doing wrong from that.

After inspecting the experimenter's board's schematic (page 18) I found that the DB connector is connected to P2.4 & P2.5 which is the USCI_A0. At first I tried configuring it on my own with no success. So next I looked at the associated example code for this particular experimenter's board. Although there isn't a specific rs-232 example there I did find that the "Capacitive Touch Pad" and "Wireless interface using MSP430" projects both use the USCI_A0 for rs-232 communication (FG4618 host_comms.c & hal_uart.c respectively). I tried to adapt my code based on those examples to no avail. So, next I looked at the example code associated with the MSP430FG4618 and found what looked like a decent example, namely, msp430xG46x_uscia0_uart_9600.c . At first I tried adapting my code to what is done in that example but it did not work so I tried running the example code its self but that did not work either. After exhausting all combinations of what I could think to do to get it working I resorted to searching the internet... I found a surprising number of posts from people having a similar problem... most of them were questions from a person that just didn't research their issue enough and was an easy fix. A good number of threads about this have no conclusion at all and are very little help. I did find some useful information but nothing that has enabled me to fix this issue on my own. Now I'm making this post in hopes that someone will be able to help me get a working example for simple RS-232 communication using the MSP430FG4618/F2013 Experimenter's Board.

Now that I've given you the background information I'll show you the code I've been working with (you can find the example code I used in the links I posted). Right now I'm just trying to transmit characters and once I get that working I'll start worrying about receiving characters.

My main only blinks a LED to let me know the code has been flashed and is running.... It calls a function called UART_Init() that as the name implies initializes the UART (USCI in UART mode).

void main(void)

{

WDTCTL = WDTPW + WDTHOLD; // Stop WDT

SCFQCTL=31; //Set System Frequency to 1048 Khz

UART_Init2(); //Call UART initialization function //UART_Init();

P5DIR |= 0x02; // Set P5.1 to output direction (LED Pin)

_EINT(); //Done Initilizing so Enable interrupts

while(1)

{

volatile unsigned int i; // volatile to prevent optimization

P5OUT ^= 0x02; // Toggle P5.1

i = 10000; // SW Delay

do i--; while (i != 0);

UART_Write("HelloWorld!\n",12);

}

return;

}

//--------------------------------------------------------------------------------------------------------------------------------------------------------------

void UART_Init()

{

UCA0CTL1 |= UCSWRST; //USCI must be in reset state for configuration

P2SEL |= BIT4; //Set up pins used by peripheral unit (USCI_A0) i.e. P2.4 = USCI_A0 TXD

UCA0CTL1 |= UCSSEL_2; // SMCLK - 1Mhz is default operation speed

UCA0BR0 = 0x6D; // 1MHz 9600

UCA0BR1 = 0x00; // 1MHz 9600

UCA0MCTL = 4; // Modulation

UCA0CTL1 &= ~UCSWRST; //Bring USCI out of reset since configuration has completed

ME2 |= UTXE1 | URXE1; //Enable TX and RX

IE2 |= UCA0RXIE; // Enable USCI_A0 RX interrupt

return;

}

//--------------------------------------------------------------------------------------------------------------------------------------------------------------

I have also tried:

void UART_Init2()

{

/* Configure the port with the reset bit held high */

UCA0CTL1 |= UCSWRST;

P2SEL |= (BIT4 | BIT5);

UCA0CTL0 = 0; //8-bit character

UCA0CTL1 = UCSSEL_2; //SMCLK

/* Set the bit rate registers for 115200 baud */

UCA0BR0 = 9;

UCA0BR1 = 0;

UCA0MCTL = UCBRS_1;

UCA0STAT = 0;

UCA0TXBUF = 0;

UCA0CTL1 &= ~UCSWRST;

return;

}

//--------------------------------------------------------------------------------------------------------------------------------------------------------------

Below I have attached a picture of my full setup and then a close up of the exp board so that you can see my jumper settings

I realize this question comes up a lot on these boards and I've read all the posts I can find related to this, but I have been unable to find anything with concrete information that I can use to get this working. I'm hoping I can get a good discussion going on this issue that can serve as a goto for resolving questions like this (unless one already exists in which case please link it to me as I was unable to find it after some considerable searching).

Thank you for your time and hopefully any help you provide,

~Josiah s. Yeagley

over 14 years ago

0 Joerg Quinten over 14 years ago

Guru 17650 points

Hi,

you're saying that you have tested 'msp430xG46x_usart1_uart_9600.c' without succes. Are you shure you've configured your terminal the right way? Is the 32khz Xtal in place (sorry, but I've never worked with this experimenter board)? Which kind of RS232-to-USB converter are you using? Is this part correctly set up?

The examples shown in http://www.ti.com/lit/zip/slac118 should run out of the box. I recommend to test the connection MSP430 <-> PC with this UNMODIFIED example. If everything works as expected you can start modifying it.

Rgds
aBUGSworstnightmare

P.S. Here's another recommended reading for you http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/55315.aspx (in summary: do not tag you questions! And - if you need too - keep it short!)

0 Josiah Yeagley over 14 years ago in reply to Joerg Quinten

Prodigy 60 points

First off thank you for your response :-) I appreciate you taking the time to help.

I tested "msp430xG46x_uscia0_uart_9600.c" not "msp430xG46x_usart1_uart_9600.c" and I was unable to successfully communication with RS-232 using the DB 9 connector on the Experimenter's Board. I provided a link to the product page of the UART to USB bridge that I am using in my opening post and it is setup correctly. The DB 9 connector is connected to pins 75 & 74 on the MSP430FG6418 which are P2.4 & P2.5, as well as, UCA0TXD UCA0RXD respectively. So to use the DB 9 connector one must use the USCI A0 Module.

That being said both "msp430xG46x_uscia0_uart_9600.c" and "msp430xG46x_usart1_uart_9600.c" work if you connect using their respective pins on Header 3. This leads to a bit of confusion which I will detail in a bit, but first I want to show you what I mean using the pins on header 3.

Here I am using "msp430xG46x_usart1_uart_9600.c" which uses the USART1 module which is NOT connected to the DB 9 connector.

The code compiles, flashes, and executes fine and Echo's what is received. Again, this does not use the DB9 connector that can be seen in the bottom of the picture in the middle. I want to use the DB 9 connector and that is connected to the USCI_A0 module.

Now upon inspecting the pin-out for the MSP430FG4618 it says that BOTH Pin 46/P4.7 and Pin 75/P2.4 are UCA0TXD and that BOTH Pin 47/P4.6 and Pin 74/P2.5 are UCA0RXD....

(click on the picture to enlarge it) and in fact if I use "msp430xG46x_uscia0_uart_9600.c" and connect to P4.7 and P4.6 on header 3 then I am able to connect and communicate over RS232 using the USCI in UART mode; However, P4.7 & P4.6 are NOT connected to the DB 9 connector P2.4 & P2.5 are.

Here is a picture of me using the USCI_A0 in UART mode using P4.7 & P4.6 on header 3 which works

So the USCI is working correctly in UART mode with "msp430xG46x_uscia0_uart_9600.c" but only if I connect to P4.6 & P4.7 which are not connected to DB 9 connector as shown below:

So I've narrowed the problem down to... How do I get the USCI to use P2.4 and P2.5 instead of P4.6 and P4.7???? and why does the MSP430FG6418 have 2 pins mapped to the same module???

~Josiah s. Yeagley

PS: Sorry about tagging my question it was my first post here and I was unfamiliar with the posting guidelines of this forum.

0 Jens-Michael Gross over 14 years ago in reply to Josiah Yeagley

Guru 227245 points

Josiah Yeagley said:
PS: Sorry about tagging my question it was my first post here and I was unfamiliar with the posting guidelines of this forum.

you can edit the tags usign the 'edit tags' icon :)

To answer your question:
The 4618 has no port mapping module, so the port pins are hardwired where they are. Some may be hardwired to two diferent port pins (and are multiplexed with these pins through the PxSEL registers), but you cannot route the signals to any other pin.

But in your case, the USCI pins are routed to both pins internally. All you have to do is to set P2SEL|=0x30 and the USI pins are connected with P2.4/P2.5. The original isntruction in sthe samle code is most likely P4SEL |= 0xc0.

You can even activate both routings at the same time, but this does not mean the two pins are direclty connected. They are buffered anyway. And having two RX pins won't make sense.

Anyway, USCI and USART (you mention both demo codes) are two different things. Even if serving the same purpose, the handling of the interrupts, even the initialisation and many of the control bits are different. SO the USCI example code won't work with the USART and vice versa.

It seems that the demo code you're using was writen for the processor, but not for this particular board, hence the confusion with the port pins.
In general, the demo code is a nice thing to tell that things are working, but it does usually not tell WHY it is workign an HOW you have to modify it for even minimal different problems (such as using the alternative port pins)

0 Josiah Yeagley over 14 years ago in reply to Jens-Michael Gross

Prodigy 60 points

Thank you! :-) That ended up being the answer I was looking for.

In the event that someone finds this post through a search... I've written an example program that'll show them how to use the DB 9 connector (aka serial connector) and a few other things on the Experimenter's Board.

You can find a nicely formatted version with syntax highlighting here: http://pastebin.com/nCC0pkyX

and I've also attached a zipped c-source file: 2630.MSP430_ExpB_RS232.zip

But if your just browsing and don't want to click on those links... I've pasted it below

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

* MSP430FG4618/F2013 Experimenter's Board Example using DB 9 connector for RS-232 communication.

* It uses the USCI in UART mode and Timer A to transmit "Hello World!" every second and echo

* recieved data. It also blinks a led to indicate the code was properly flashed and is running.

* Josiah s. Yeagley

* October 5th, 2010

* Built with Code Composer Studio Version: 4.1.2.00027

#include "msp430xG46x.h"

//Forward Declarations aka Function Prototypes

void TimerA_Init();

void USCIA0_UART_P2_Init();

void USCIA0_UART_Transmit(unsigned char c);

void SendString(char* str);

void SendBuffer(unsigned char* buf,unsigned short length);

void Handle_Incomming(unsigned char* pkt, unsigned short len);

/* RECEIVE_BUFFER_SIZE is the maximum number of bytes a packet can contain.

* If a packet is larger than RECEIVE_BUFFER_SIZE then the first RECEIVE_BUFFER_SIZE bytes are processed

* and the remaining bytes are processed seperatly in chunks less than or equal to RECEIVE_BUFFER_SIZE */

#define RECEIVE_BUFFER_SIZE 128

/* PACKET_TERMINATION_CHAR is the byte whos value signals that the packet has finished transmitting.

* This example is built for processing strings so that character is the newline constant */

#define PACKET_TERMINATION_CHAR '\n'

* Entry point for this program. It adjusts the DCO to 8Mhz, calls USCIA0_UART_P2_Init & TimerA_Init, and blinks a LED.

void main(void)

{

volatile unsigned int i,j; //Local Temp Variable -- Volatile to prevent optimization

_DINT(); //Disable Interrupts -- For initlization purposes

WDTCTL = WDTPW + WDTHOLD; //Stop WDT

Set System Clock Frequency to (121+1) * 32786 * 2 = 7.995392Mhz

This freq. allows for 2400 - 230400 bit rate UART operation with less than 0.86% error

FLL_CTL0 = (DCOPLUS | XCAP18PF); //Enable Frequency Multiplier (DCO+) and XIN/XOUT caps to 18pF

SCFI0 = (FLLD_2 | FN_8); //Set Multiplier to 2, and DCO range to 8MHz nominal

SCFQCTL = 121; //7.995392Mhz Operation with No Modulation

USCIA0_UART_P2_Init(); //Configure USCI for UART Mode and Use P2.4&P2.5 which are connected to the DB 9 connector

TimerA_Init(); //Configure TimerA to generate an interrupt every second which will then transmit "Hello World!"

P5DIR |= 0x02; //Set P5.1 to output direction -- LED is connected to this pin

_EINT(); //Done Initilizing so reenable interrupts

while(1)

{

for(i=0;i<10000;i++)

for(j=0;j<50;j++)

; //LED Bink Delay

P5OUT ^= 0x02; //Toggle P5.1 using XOR

}

//---------------------------------------------------------------------------------------------------------------

* This function sets up Timer A to use ACLK which is a 32.768kHz Watch Crystal, to run in "Up Mode" and generate

* an interrupt every second

void TimerA_Init()

{

TACTL = (TASSEL_1 | TACLR); //Use ACLK 32.768Khz, and reset TAR

TACCTL0 = CCIE; //Enable the Capture/Compare Interrupt

TACCR0 = 32767; //The counter will reach 32767 in approx. 1 second

TACTL |= MC_1; //Set it to run in 'up mode' and thus start the counter

}

//---------------------------------------------------------------------------------------------------------------

* This function is the interrupt service routine for Timer A. The timer is setup

* to generate a interrupt and run the contents of this function every second.

#pragma vector=TIMERA0_VECTOR

__interrupt void Timer_A (void)

{

SendString("HelloWorld!\n"); //Transmit Hello World!

}

//---------------------------------------------------------------------------------------------------------------

* This function sets up the USCI A0 in UART mode and sets the internal multiplexer to use P2.4 & P2.5

* and not P4.6 & P4.7. This is done because the DB 9 connector on the MSP430FG4618/F2013 Experimenter's

* Board is connected to those pins which are not the default pins used by the USCI. Note: This function

* is set to use a 115200 bit rate if you want to use a different bitrate use the tool at the following

* website: http://www.daycounter.com/Calculators/MSP430-Uart-Calculator.phtml

void USCIA0_UART_P2_Init()

{

UCA0CTL1 |= UCSWRST; //Configure the USCI with the reset bit held high

P4SEL &= ~0x0C0; //P4.7,6 != USCI_A0 RXD/TXD

P2SEL |= 0x30; //Set the USCI to use P2.4 and P2.5 for RX/TX

UCA0CTL1 |= UCSSEL_2; //Use SMCLK

UCA0BR0 = 0x45; //Set Bit Rate to 115200bps with a 8Mhz clock

UCA0BR1 = 0x00;

UCA0MCTL = 0x4A; //Modulation

UCA0CTL1 &= ~UCSWRST; //Done configuring so take USCI out of reset

IE2 |= UCA0RXIE; //Enable USCI_A0 RX interrupt

return;

}

//---------------------------------------------------------------------------------------------------------------

* This function is the interrupt service routine for the USCI A0 setup in

* UART mode with the receive interrupt enabled. The microcontroller will

* call this ISR (if enabled) once a byte is received thus allowing for other

* code to be executed while still "listening" for data over the RX line.

#pragma vector=USCIAB0RX_VECTOR

__interrupt void USCIA0RX_ISR (void)

{

unsigned char ReceivedByte;

static unsigned char Buffer[RECEIVE_BUFFER_SIZE+1];

static int count = 0;

ReceivedByte = UCA0RXBUF; //Retrieve the transmitted data from the receive buffer

if(ReceivedByte != PACKET_TERMINATION_CHAR || count >= RECEIVE_BUFFER_SIZE)

{

Buffer[count] = ReceivedByte;

count++;

}

else

{

Buffer[count] = ReceivedByte;

Buffer[++count] = PACKET_TERMINATION_CHAR; //Make sure its terminated (needed in event of data overflow)

Handle_Incomming(Buffer,count); //Send completed packet to be processed

count = 0;

}

//---------------------------------------------------------------------------------------------------------------

* The following function is used to process incomming packets.

* It is currently set up for testing purposes and just retransmits the recieved packet.

* It'll require proper packet processing operations that'll depend on the packet protocol

void Handle_Incomming(unsigned char* pkt, unsigned short len)

{

SendBuffer(pkt,len); //Don't process packet just retransmit contents

return;

}

//---------------------------------------------------------------------------------------------------------------

* The following function uses the USCI A0 setup in UART mode to transmit a single byte over RS-232

void USCIA0_UART_Transmit(unsigned char c)

{

while(!(IFG2 & UCA0TXIFG)); //Wait until transmit buffer is empty

UCA0TXBUF = c; //Send character

return;

}

//---------------------------------------------------------------------------------------------------------------

* The following function sends a null terminated c string over RS-232 using the USCI A0 in UART mode

void SendString(char* str)

{

unsigned short i;

for(i=0;str[i] != '\0';i++) USCIA0_UART_Transmit(str[i]); //Send string one character at a time

return;

}

//---------------------------------------------------------------------------------------------------------------

* The following function sends an array of bytes of a given length over RS-232 using the USCI A0 in UART mode

void SendBuffer(unsigned char* buf,unsigned short length)

{

unsigned short i;

for(i=0;i<length;i++) USCIA0_UART_Transmit(buf[i]); //Send buffer one character at a time

return;

}

//-------------------------------------------------------------------------------------------------------------

MSP430_ExpB_RS232.zip

0 Jens-Michael Gross over 14 years ago in reply to Josiah Yeagley

Guru 227245 points

Thanks for sharing your code. Maybe you can post it to the MSP wiki? There should be a section for code 'snippets' and for the experimenters board.
I fear it will be forgotten too soon int his forum (the search isn't very useful if yon don't know exactly which term to search for)

0 Josiah Yeagley over 14 years ago in reply to Jens-Michael Gross

Prodigy 60 points

I can't seem to find the area your referencing.

0 Jens-Michael Gross over 14 years ago in reply to Josiah Yeagley

Guru 227245 points

Strange, the link to the TI internal Wiki is gone forom the ressources page:

http://processors.wiki.ti.com/index.php/MSP430

There's an experimenters board section.

Well, it seems there didn't happen much on this Wiki since I visited it last time 6 months ago.

0 karan patel1 over 11 years ago in reply to Jens-Michael Gross

Expert 1085 points

i have same problem. i tried your code on board but it stiil error.

i am getting this kind of data insted of hello world.

------------------------------------------------------------------------------------------------------------

ö0H6•.ö0RH6•>ö0H6•>öpv•>ö0R6•>ö0H6•>ö0H6•.öpRv•>ö0RH6•>ö0H6•.ö0R&•>ö0H6•>ö0H6•.ö0H6•.öpv•>ö0R6•>ö0H6•>ö0H6•.ö06•.ö0R&•>ö0RH6•>ö0H6•.öp6•>ö0R6•>ö0H6•>ö0H6•.öpRv•>ö0H6•>ö0H6•>öp6•.ö0Rv•>ö0RH6•>ö0H6•.öp6•>ö0R6•>ö0RH6•>ö0H6•.öp6•.ö0R6•>ö0H6•.öp6•>ö0RH6•>ö0H6•.öpR6•>ö0H6•>ö0v•>ö0R6•>ö0H6•>ö0H6•.öpv•>ö0R6•>ö0H6•>ö0H6•.ö0R&•>ö0RH6•>ö0H6•>ö0H6•.ö0v•>ö0RH6•>ö0H6•>ö0H6•.ö0R&•>ö0H6•>ö0H6•.ö0Rv•>ö0RH6•>ö0H6•.ö0H6•.öpv•>ö0R6•>ö0H6•>ö0H6•.öp6•>ö0RH6•>ö0H6•>öp6•>ö0R6•>ö0H6•>ö0H6•.öp6•.ö0R6•>ö0RH6•>ö0H6•>ö0H6•.ö0Rv•>ö0R6•>ö0H6•>ö0H6•.öpv•>ö0RH6•>ö0H6•.öp6•>ö0R6•>ö0H6•>ö0H6•.ö0RH6•>ö0H6•.öpRv•>ö0RH6•>ö0H6•>ö0H6•.öp6•.ö0R6•>ö0H6•>ö0H6•.öpRv•>ö0RH6•>ö0H6•.ö0H6•.ö0R&•>ö0H6•>ö0H6•.ö0Rv•>ö0R6•>ö0H6•>ö0H6•>ö0H6•.öpRv•>ö0R6•>ö0H6•>ö0H6•.ö0v•.ö0R&•>ö0RH6•>ö0H6•.ö0H6•.öpv•>ö0RH6•>ö0H6•>ö0H6•.öpv•>ö0R&•>ö0H6•>ö0H6•.ö0R&•>ö0RH6•>ö0H6•>öp6•.ö0R6•>ö0H6•>ö0H6•.ö0Rv•>ö0RH6•>ö0H6•.öpv•>ö0R6•>ö0H6•>ö0H6•.öpv•.ö0R6•>ö0H6•>ö06•>ö0R6•>ö0H6•>ö0H6•.ö0R&•>ö0RH6•>ö0H6•.öp6•>ö0R6•>ö0H6•.öp6•.ö0R6•>ö0H6•>ö06•.ö0Rv•>ö0RH6•>ö0H6•.öp6•>ö0RH6•>ö0H6•.ö0Rv•>ö0RH6•>ö0H6•>ö06•>ö0R6•>ö0H6•.öp6•.ö0R&•>ö0H6•>ö0H6•.öpRv•>ö0RH6•>ö0H6•.öpRv•>ö0R6•>ö0H6•>ö0H6•.öp6•.ö0R&•>ö0R6•>ö0H6•>ö0H6•.ö0R6•>ö0H6•>ö0H6•>ö0H6•.öpv•>ö0R6•>ö0H6•.öpv•>ö0Rv•>ö0R6•>ö0RH6•>ö0H6•>ö0H6•>ö0H6•.öpv•>ö0RH6•>ö0H6•>ö0H6•.ö0Rv•>ö0RH6•>ö0H6•>ö0H6•.öpRv•>ö0R6•>ö0H6•>ö0H6•.öpRv•>ö0R6•>ö0H6•.ö06•>ö0Rv•>ö0RH6•>ö0H6•.öpRv•>ö0RH6•>ö0H6•>

------------------------------------------------------------------------------------------------------------------------------------

port setting is ok

0 Jens-Michael Gross over 11 years ago in reply to karan patel1

Guru 227245 points

karan patel1 said:
i am getting this kind of data insted of hello world.

Cna have multiple reasons: your PCs COM port isn't providing enough current to driver the isolated RS232 part of the board, or your baudrate is wrong (either on the PC side or the MSP side). Or the UART configuration is wrong (e.g. wrong bit order sent etc.). But likely you're sending slower than the PC expects. The bit pattern of the 'code' you see looks a bit like you're sending half as fast as the PC expects, so one bit you send becomes two on the PC.

0 karan patel1 over 11 years ago in reply to Jens-Michael Gross

Expert 1085 points

i am not understand this statment i think i have this kind of problem '' But likely you're sending slower than the PC expects. The bit pattern of the 'code' you see looks a bit like you're sending half as fast as the PC expects, so one bit you send becomes two on the PC.'' but in my program i set buad rate correctly then why this happen?????

here is my program it read data from HYT-221 sensor and then send 1 to pc useing USCI in UART mode;

-------------------------------------------------------------------------------------------------------------------------------------------------------------

//******************************************************************************
// MSP430xG461x Demo - USCI_B0 I2C Master TX multiple bytes to MSP430 Slave
//
// Description: This demo connects two MSP430's via the I2C bus. The master
// transmits to the slave. This is the master code. It continuously
// transmits an array of data and demonstrates how to implement an I2C
// master transmitter sending multiple bytes using the USCI_B0 TX interrupt.
// ACLK = 32kHz, MCLK = SMCLK = TACLK = BRCLK = 1MHz
//
// /|\ /|\
// MSP430xG461x 10k 10k MSP430xG461x
// slave | | master
// ----------------- | | -----------------
// -|XIN P3.1/UCB0SDA|<-|---+->|P3.1/UCB0SDA XIN|-
// 32kHz | | | | | 32kHz
// -|XOUT | | | XOUT|-
// | P3.2/UCB0SCL|<-+----->|P3.2/UCB0SCL |
// | | | |
//
// Andreas Dannenberg/ M. Mitchell
// Texas Instruments Inc.
// October 2006
// Built with CCE Version: 3.2.0 and IAR Embedded Workbench Version: 3.41A
//******************************************************************************
#include "msp430xG46x.h"

volatile unsigned char k,d,t,*prxdata,s,txdatactr,r,cnt=0;
volatile unsigned char data,rxdatactr,rxdata[5]={0,0,0,0,0},sdatactr;
int i;
unsigned long int val_a;
long double val_b;
float humidity,temp;
void delay(int i)
{
while(i!=0)
{
i--;
}
}
void uartset (void)
{
UCA0CTL1 |= UCSWRST;
P4SEL &= ~0x0C0;
P2SEL |=0x30;
// P2DIR |=0x04;

UCA0CTL1 |= UCSSEL_2; // SMCLK
UCA0BR0 = 0x6D; // 1MHz9600
UCA0BR1 = 0x00; //
UCA0MCTL |= UCBRS_2;
UCA0CTL1 &= ~UCSWRST;
}
void cal(void)
{
val_a=rxdata[0];
if((val_a & 0xC0)!=1)
{
val_a=val_a << 8;
val_a=val_a + rxdata[1];
val_a=val_a & 0x3FFF;
// val_a=val_a*100;
val_b=(val_a)*(0.006103515625);
humidity=val_b;
val_a=rxdata[2];
val_a=val_a << 8;
val_a=val_a + rxdata[3];
val_a=val_a >>2;
val_a=val_a & 0x3FFF;
//val_a=val_a*165;
val_b=(val_a)*(0.01007080078125);
temp=val_b-40;
}
}

void main(void)
{
WDTCTL = WDTPW + WDTHOLD;

delay(60000);
uartset();
P3SEL |= 0x06;
//P2SEL |=0x00;
P5SEL =0x00;
P5DIR =0x02;
//P2DIR |= 0x06;
P5OUT=0x00;
UCB0CTL1 |= UCSWRST;
UCB0CTL0 = UCMST + UCMODE_3 + UCSYNC;
UCB0CTL1 = UCSSEL_2 + UCSWRST;
UCB0BR0 = 10;
UCB0BR1 = 0;
UCB0I2CSA = 0x28;
UCB0I2CIE =0x09;
UCB0CTL1 &= ~UCSWRST;
P5OUT |=0x02;

while (1)
{
delay(60000);
P5OUT ^=0x02;
// UCB0CTL1 &= ~UCSWRST;
// P2OUT=0x04;
// delay(6000);
// P2OUT=0x00;
// delay(6000);
txdatactr=1;
IE2 |= UCB0TXIE;
k=1;
__bis_SR_register(GIE);
UCB0CTL1 |= UCTR + UCTXSTT;
while(k);
while (UCB0CTL1 & UCTXSTP);

// P2OUT=0x04;
// delay(6000);
// P2OUT=0x00;
// delay(6000);
t=1;
rxdatactr=3;
prxdata= &rxdata[0];

IE2 |= UCB0RXIE;
UCB0CTL1 &= ~UCTR;
UCB0CTL1 |= UCTXSTT;
__bis_SR_register(CPUOFF + GIE);

while (UCB0CTL1 & UCTXSTP);
// UCB0CTL1 |= UCSWRST;
cal();
// UCA0CTL1 &= ~UCSWRST;
cnt=0;
//r=1;
// IE2 |= UCA0TXIE;
// __bis_SR_register(CPUOFF + GIE);
// while(r);
do{
}while ((IFG2&0x02)==0);
UCA0TXBUF =1;
// UCA0CTL1 |= UCSWRST;

//UCB0CTL1 &= ~UCTXSTP;
}
}

//------------------------------------------------------------------------------
// The USCIAB0TX_ISR is structured such that it can be used to transmit any
// number of bytes by pre-loading TXByteCtr with the byte count. Also, TXData
// points to the next byte to transmit.
//------------------------------------------------------------------------------
#pragma vector = USCIAB0TX_VECTOR
__interrupt void USCIAB0TX_ISR(void)
{
if(k==1)
{
if(txdatactr)
{
UCB0TXBUF=0x28;
txdatactr--;
}
else
{

UCB0CTL1 |= UCTXSTP;
//UCB0CTL1 &= ~UCTXSTT;
IFG2 &= ~UCB0TXIFG;
IE2 &= ~UCB0TXIE;
k=0;
//__bic_SR_register_on_exit(CPUOFF);
}

}

if(t==1)
{
if (rxdatactr)
{

*prxdata=UCB0RXBUF;
if((IFG2 & UCB0RXIFG)==0)
{
//P5OUT ^=0x02;
}

if(rxdatactr==1)
{
UCB0CTL1 |= UCTXSTP;
}
rxdatactr--;
prxdata++;
}
else
{
*prxdata=UCB0RXBUF;
// UCB0CTL1 |= UCTXSTP;
IE2 &= ~UCB0RXIE;
t=0;
__bic_SR_register_on_exit(CPUOFF);
}
}

if(r==1)
{
if(cnt==0)
{
UCA0TXBUF =1;

}
if(cnt==1)
{
UCA0TXBUF =2;

}
if(cnt==2)
{
UCA0TXBUF =3 ;

}
if(cnt==3)
{
UCA0TXBUF =4 ;

}
if(cnt==4)
{
UCA0TXBUF =5 ;

}
if(cnt==5)
{
UCA0TXBUF =6 ;

}
if(cnt==6)
{
IE2 &= ~UCA0TXIE;
cnt=0;
r=0;
__bic_SR_register_on_exit(CPUOFF);
}
cnt++;
IFG2 &= ~UCA0TXIFG;
}

}

#pragma vector=USCIAB0RX_VECTOR
__interrupt void USCIA0RX_ISR (void)
{
if((UCB0STAT && UCNACKIFG)==1)
{
P5OUT =0x00;
UCB0STAT &=~UCNACKIFG;
}

if((UCB0STAT & UCALIFG)==1)
{
P5OUT |=0x00;
}
}

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

neglect if(r==1) loop in isr i disable it. my buad rate is 9600 on controller and pc side

0 Jens-Michael Gross over 11 years ago in reply to karan patel1

Guru 227245 points

karan patel1 said:
but in my program i set buad rate correctly

Do you? In your program you do not program the clock module, so the CPU and therefore the USCI base clock is, well, an unknown speed. You just assume that the CPU speed is 1MHz, but this is only true if the FLL is adjusting the DCO based on an external watch crystal (which must be up and running before).
Likely, the FLL is without reference (0Hz), so it adjusts the DCO tho the lowest frequency possible (0*31 is still 0) , which is ~0.65MHz. So your baudrate is 0.65*9600Bd too, which fits my impression of half the baudrate the PC expects.

0 karan patel1 over 11 years ago in reply to Jens-Michael Gross

Expert 1085 points

ok i understand your sentence.

you feel that due to not setting dc0 this problem occure. i am not set dco because in sample example i relise that with out seeting by default SMCALK =MCALK=1.048576MHz. but if your reason is true then i should not able to communicate with my sensor useing i2c. because my sensor works on at 100KHz-400KHz. and i have set devider in my programme for 100KHz. so if its 0.65mhz then my clack is of 65khz which my sensor should not support. but in my case its working. and useing trial and error method i found my pc receive correctly for following buad rate.

2500,2600,2700 other than this create errornous data

so i dont know where is the problem??????????????????????//

0 Jens-Michael Gross over 11 years ago in reply to karan patel1

Guru 227245 points

karan patel1 said:
i am not set dco because in sample example i relise that with out seeting by default SMCALK =MCALK=1.048576MHz.

Indeed, the default settings will result in this frequency if (and only if) there's a watch crystal attached that fits the default driving strength and load capacitance and it is properly running.
Which doesn't seem to be the case for you.

karan patel1 said:
then i should not able to communicate with my sensor useing i2c. because my sensor works on at 100KHz-400KHz.

No. I2C specification defines two (actually 3, but the third isn't supported by the MSP) frequency ranges: 10..100kHz and 100..400kHz. However, both specs define the typical range and maximum frequency. Minimum frequency for I2C is 0Hz in both cases. I2C is a synchronous protocol, the master provides the clock signal. So unless you use a clock that is higher than the slave can handle or is so slow that the slave detects a timeout, I2C will work fine. The I2C slave won't complain if you tick it with 65kHz instead of 100kHz.

Now the default setting for the FLL is using a /2 divider on DCO, which means the DCO is by default running on 2.1MHz if the reference crystal is there. And MCLK/SMCLK are running on DCO/2. Assuming that the DCO switches back to 650kHz, this means MCLK and SMCLK are running on 325kHz then. Wiht a divider of 109 (0x6d), this results in a baudrate of 2981Bd (a bit more or less since the minimum DCO frequency is a bit device-dependent). Which fits your observation of ~2600Bd.

If you don#' have a crystal or doN't want to use one, you have only one option: determine the optimum DCO setting for your specific MSP chip by try and error. You may outpu tMCLK or SMCLK to aport pin and check it with a scope, disable the FLL and try different DCO settings until you find the one that fits for 1MHz or whatever frequency you want.
(That's more or less how the calibration values for 2x family - which has no FLL to auto-adjus tthe DCO - are determined at production time).

0 karan patel1 over 11 years ago in reply to Jens-Michael Gross

Expert 1085 points

thank you very much i think you are right because in debugging i found occilator fault remains on permanantly .so may it not work properly..

0 Rounak Singh Narde over 11 years ago in reply to Josiah Yeagley

Prodigy 50 points

thanks,,,,,for the program...............i was frustrated for whole day to get uart working..........thanks again.............

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430FG4618/F2013 Experimenter's Board RS-232 Issue