MSP430F133: Receiving Strings via bluetooth, storage of strings and transmission.

I think you need to provide the code.

What are you getting back? garbage? or does it seem to make sense in some way?

Please use insert code facility.

You don't nul terminate RXBuffer before sending it to transmit. I tend to add a nul after every received character, so that it is always nul terminated.

It is also bad form to wait so long in an interrupt.

Will adding a null after every received character still allow the string to be transmitted as one? 

The idea is that you treat every character as the end of the string and add a nul. When the next character comes in, you overwrite that nul with the new character and add another one.

In your case, you could also add the nul when you get the '\n'.

 char receivedChar = UCA0RXBUF;
            if (receivedChar == '\n') {
                rxBuffer[rxIndex] = '\0'; // Null-terminate the string
                flashLED(); // Visual indication of data reception
                LCDDisplayScrollText(); // Display "DATA RECEIVED" on LCD
                transmitString(rxBuffer); // Transmit the received string back
                rxIndex = 0; // Reset index for next string

Is this an appropriate addition of the null terminator?

Yup. Note you will not have a '\n' in your string.

This issue unfortunately still persist, the '\n' comes as part of the string which is sent via bluetooth so everything before this should be stored, however the data being transmitted is still incorrect.

The text coming out is cohert for example if 'Hi' is sent xi or RJ, however it can sometimes be much further off.

#include <msp430.h>

#define BUFFER_SIZE 256

char RXData[BUFFER_SIZE];
int rxIndex = 0;

void Init_Clock(void) {
    __bis_SR_register(SCG0);
    CSCTL3 |= SELREF__REFOCLK;
    CSCTL0 = 0;
    CSCTL1 &= ~(DCORSEL_7);
    CSCTL1 |= DCORSEL_3;
    CSCTL2 = FLLD_0 + 243;
    __delay_cycles(3);
    __bic_SR_register(SCG0);
    while (CSCTL7 & (FLLUNLOCK0 | FLLUNLOCK1));
    CSCTL4 = SELMS__DCOCLKDIV | SELA__REFOCLK;
}

void Init_UART(void) {
    P1SEL0 |= BIT0 | BIT1;

    UCA0CTLW0 |= UCSWRST;
    UCA0CTLW0 |= UCSSEL__SMCLK;

    UCA0BR0 = 52;
    UCA0BR1 = 0;
    UCA0MCTLW = 0x4900 | UCOS16 | UCBRF_1;
    UCA0CTLW0 &= ~UCSWRST;
    UCA0IE |= UCRXIE;
}

void transmitString(void) {
    int i;
    for (i = 0; i < rxIndex; i++) {
        while (!(UCA0IFG & UCTXIFG));
        UCA0TXBUF = RXData[i];
    }
    rxIndex = 0;
    RXData[rxIndex] = '\0';
}

void main(void) {
    WDTCTL = WDTPW | WDTHOLD;
    Init_Clock();
    PM5CTL0 &= ~LOCKLPM5;
    Init_UART();

    __bis_SR_register(GIE);

    while (1) {
        __no_operation(); // Placeholder for background tasks.
    }
}

#pragma vector=USCI_A0_VECTOR
__interrupt void USCI_A0_ISR(void) {
    switch (__even_in_range(UCA0IV, USCI_UART_UCTXCPTIFG)) {
        case USCI_NONE: break;
        case USCI_UART_UCRXIFG:
            if (rxIndex < BUFFER_SIZE - 1) {
                char receivedChar = UCA0RXBUF;
                if (UCA0STATW & UCRXERR) {
                    UCA0STATW &= ~(UCFE | UCOE | UCPE | UCBRK); // Clear errors
                    rxIndex = 0; // Reset the buffer
                    RXData[rxIndex] = '\0';
                } else {
                    RXData[rxIndex++] = receivedChar;
                    RXData[rxIndex] = '\0';

                    if (receivedChar == '\n') {
                        transmitString(); // This assumes transmission is correct
                        rxIndex = 0;
                        RXData[rxIndex] = '\0';
                    }
                }
            } else {
                transmitString(); // Buffer full, transmit what we have
                rxIndex = 0;
                RXData[rxIndex] = '\0'; // Reset the buffer
            }
            break;
        case USCI_UART_UCTXIFG: break;
        case USCI_UART_UCSTTIFG: break;
        case USCI_UART_UCTXCPTIFG: break;
        default: break;
    }
}

I have trialled new UART configuration and implementation of a clock function, which has improved the transmission of data, however the incorrect output data issue still remains. Any help would be greatly appreciated.  

Time to put a debugger with a break in the transmit function and a  scope on the serial line to see if what you are sending is what comes out.

Maybe your receiver needs more time between bytes.

I have uploaded an image of the buffer when the message HI was sent, as you can see some unneeded data is also being sent.

Hi, Keith

Have you tried using a logic analyzer to observe Rx on the hardware?

Regards,

Helic