Problem interfacing with GSM Modem - MSP430 UART

Hi,

Is it possible the GSM modem requires flow control of some sort (Xon/Xoff)?  Sounds like there is two stage buffer on the modem and all of the first characters sent are overwritten by the last two.

HTH,

Barry

Hi all,

Thank you very much for the replies. It turns out the cause was indeed the missing GND connection. The modem is now communicating with the MSP430.

sir I am facing the problem with msp430 and GSM. I will clearly describe my situation.
I am able to make call and send SMS through at commands from GSM module using msp430.
But the problem is when I am doing reverse way i.e calling from cell to GSM msp430 is not responding to that.
Can you please help me out sir????

If you can send, then at least the MSP and the modem are running and the TX conenction is working.
Buw why th eopposite side doesn't work will remain a mystery without more information. That is: schematics, code, maybe scope or logic analyzer captures form the signals.
Also 'not responding' can mean a lot. Does it not notice the incoming SMS or does it just not properly answer? How does/shall it notice? I'm no GSM modem expert(never worked with one) , so I don't know how incoming SMS is handled by the modem.

Sir my coding is fine!! I will post the code I am able to print AT commands on putty using msp430g2553. Also I am able to make call and send SMS by sending AT commands through putty. So basically GSM is fine but the problem is when I connect msp430g2553 to GSM I am able to see At commands on serial monitor but the response is Error. Can u help me out what might be the problem?

#include <msp430g2553.h>

int value;

char str[2];

void my_itoa(unsigned int num, char *str)

{

    unsigned char rem = 0;

    char *temp = str;

    char *str1 = str;

    char temp1;

 

    if (num != 0)

    {

        while(num > 0)

        {

            rem = num % 10;

            *str = rem + 48;

            str++;

            num = num / 10;

        }

        *str = '\0';

        str = str1;

 

        while(*temp != '\0')

        {

            temp++;

        }

        temp = temp - 1;

 

        while(temp >= str)

        {

            temp1 = *str;

            *str = *temp;

            *temp = temp1;

            str++;

            temp--;

        }

    }

    else

    {

        *str = 48;

        str++;

        *str = '\0';

    }

}

 

int uart_putchar(char c)

{

    /* Wait for the transmit buffer to be ready */

   while (!(IFG2 & UCA0TXIFG));

 

    /* Transmit data */

    UCA0TXBUF = (char ) c;

 

    return 0;

}

 

int getch(void)

{

    int chr = -1;

 

    while(!(IFG2 & UCA0RXIFG));

 

    chr = UCA0RXBUF;

 

 

    return chr;

}

 

void print(char *str)

{

    while(*str != '\0')

    {

        uart_putchar(*str);

        str++;

    }

 

    //uart_putchar(' ');

}

 

int distance;

 

int main()

{

    if (CALBC1_1MHZ==0xFF)                  // If calibration constant erased

  {

    while(1);                               // do not load, trap CPU!!

  }

  DCOCTL = 0;                               // Select lowest DCOx and MODx settings

  BCSCTL1 = CALBC1_1MHZ;                    // Set DCO

  DCOCTL = CALDCO_1MHZ;

  P1SEL = BIT1 + BIT2 ;                     // P1.1 = RXD, P1.2=TXD

  P1SEL2 = BIT1 + BIT2 ;                    // P1.1 = RXD, P1.2=TXD

  UCA0CTL1 |= UCSSEL_2;                     // SMCLK

  UCA0BR0 = 104;                            // 1MHz 9600

  UCA0BR1 = 0;                              // 1MHz 9600

  UCA0MCTL = UCBRS0;                        // Modulation UCBRSx = 1

  UCA0CTL1 &= ~UCSWRST;                     // **Initialize USCI state machine**

    char distance_str[10];

    char sum, checksum;

    int i,j,k;

 

    unsigned int l;

 

 

    // Disable watchdog timer

    WDTCTL = WDTPW + WDTHOLD;

 

 

    P1DIR = 0b01001001;

 

 

    TA1CTL = TASSEL_2 + ID_0 + MC_2;

    // Now just monitor distance sensor

    while(1)

    {

                        P1OUT^=BIT0;

                           print((char *)"AT");

                           uart_putchar(0x0A);

                           uart_putchar(0x0D);

                           __delay_cycles(1000000);

 

                           print((char *)"ATD9743172765;");

                             uart_putchar(0x0A);

                             uart_putchar(0x0D);

                             __delay_cycles(60000000);

 

                             __delay_cycles(600000000);

}

}

Here's a quick experiment: Try reversing your <LF,CR> sequences to send <CR,LF> instead.

Back in the Ancient Days, I recall encountering some AT parsers that insisted that CR is the AT command terminator (and ignored any LF that followed), and would fumble if the LF were sent first. I then got in the habit of sending the CR first, so I don't know if that has changed.

Of course if your Book says the LF must come first then I defer.

All terminal devices (or programs referring to a double-character line-end sequence, including the standard C console I/O) use CR/LF. I've never seen any program using LF/CR, even though this will have the same effect (go to start of next line) on a plain dumb line printer or terminal output.
So your 'habit' is actually the established standard. :)
If the book says something else, then this is more than unusual (and probably wrong).