This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP432 Rx from SIM900 doest not receive data...

Hello 

I am trying to read the phone no and Message received from the SIM900 module.

Connections as below

SIM900         MSP432

   Rx < --------- Tx

   Tx -----------> Rx

  Gnd <-------> Gnd

I could send an SMS from the code commented(attached)  but while receiving the message an interrupt is triggered but there is no data. When i debug i can see the information on Putty as "OK" when every AT command is sent to SIM900. Made sure baudrate are set to 9600 .

Debug output observed : 

Data1:
Data2:
Data3:
Data4:
Data5:
Data6:
Data7:
Data8:  
Data9:
Data10:
Data11:
Data12:
Data13:
Data14:

Output on Putty:

OK

OK

OK

OK

OK

+CMGR: "REC READ","+46728747075","","16/05/13,20:27:23+08"
turn on

OK

Please suggest where am i going wrong.

#include "driverlib.h"

#define BUFF_SIZE 8
char data2[BUFF_SIZE];
static volatile int i;
static volatile int flag=0;


char receive[]={'+','C','M','T','I',':',' ','"','S','M','"',','};   //'1'};//"+CMTI: "SM",1

//char receive1[]= {'+','C','M','G','R',':'}; // checking for receive for CMGR
char receive1[]= {"+CMGR:"}; // checking for receive for CMGR

//char receive1[]={'+','C','M','G','R',':','"','R','E','C',' ','U','N','R','E','A','D','"',',','"','+','4','6','7','2','8','7','4','7','0','7','6111','0','0','0',};
//59


/* UART Configuration Parameter. These are the configuration parameters to
 * make the eUSCI A UART module to operate with a 9600 baud rate. These
 * values were calculated using the online calculator that TI provides
 * at:
 *software-dl.ti.com/.../index.html
 */
const eUSCI_UART_Config uartConfig =
{
        EUSCI_A_UART_CLOCKSOURCE_SMCLK,          // SMCLK Clock Source
        78,                                     // BRDIV = 78
        2,                                       // UCxBRF = 2
        0,                                       // UCxBRS = 0
        EUSCI_A_UART_NO_PARITY,                  // No Parity
        EUSCI_A_UART_LSB_FIRST,                  // LSB First
        EUSCI_A_UART_ONE_STOP_BIT,               // One stop bit
        EUSCI_A_UART_MODE,                       // UART mode
        EUSCI_A_UART_OVERSAMPLING_BAUDRATE_GENERATION  // Oversampling
};

void status();
void init_gsm();
void uart_putc(unsigned char c);
void uart_puts(char *str);


void main(void)
{
	 /* Halting WDT  */
		    MAP_WDT_A_holdTimer();
lcd_init();
send_string("UART to LCD ");
send_command(0xC0);// all the information will be on 2nd line

/* Selecting P1.2 and P1.3 in UART mode */
   MAP_GPIO_setAsPeripheralModuleFunctionInputPin(GPIO_PORT_P1,GPIO_PIN1 | GPIO_PIN2 | GPIO_PIN3, GPIO_PRIMARY_MODULE_FUNCTION);

   /* Setting DCO to 12MHz */
   CS_setDCOCenteredFrequency(CS_DCO_FREQUENCY_12);

   /* Configuring UART Module */
 MAP_UART_initModule(EUSCI_A0_BASE, &uartConfig);

   /* Enable UART module */
 MAP_UART_enableModule(EUSCI_A0_BASE);

 // enable Interrupts
 enable_interrupt();

  // GSM Initiatlisation
	init_gsm();


 while(1)
}


void EUSCIA0_IRQHandler(void)
{
	uint32_t status = MAP_UART_getEnabledInterruptStatus(EUSCI_A0_BASE);
    MAP_UART_clearInterruptFlag(EUSCI_A0_BASE, status);
    if(status & EUSCI_A_UART_RECEIVE_INTERRUPT)
	{
	  data2[i] = UCA0RXBUF;
	  i++;
	 printf("Data%d: %c\n",i,data2[i]);
}
}

void uart_puts(char *str)				//Sends a String to the UART.
{
     while(*str)
     {
     MAP_UART_transmitData(EUSCI_A0_BASE,*str++);
     }
}

void uart_putc(unsigned char c)           //Sends a char to the UART.
{
	MAP_UART_transmitData(EUSCI_A0_BASE,c);
}


void enable_interrupt()

{
 MAP_UART_enableInterrupt(EUSCI_A0_BASE, EUSCI_A_UART_RECEIVE_INTERRUPT);
 MAP_Interrupt_enableInterrupt(INT_EUSCIA0);
 MAP_Interrupt_enableSleepOnIsrExit();
 MAP_Interrupt_enableMaster();
}


void init_gsm()
{
	uart_puts((char *)"AT"); // AT commands to initialize gsm modem
		uart_putc(0x0D);
		uart_putc(0x0A);
	__delay_cycles(5000000);
	uart_puts((char *)"ATe0"); // AT commands to initialize gsm modem
	uart_putc(0x0D);
	uart_putc(0x0A);
			__delay_cycles(5000000);

		uart_puts((char *)"AT+CMGF=1"); // AT commands to initialize gsm modem
		uart_putc(0x0D);
		uart_putc(0x0A);
			__delay_cycles(5000000);

			uart_puts((char *)"AT+CREG=1"); // AT commands to initialize gsm modem
			uart_putc(0x0D);
			uart_putc(0x0A);
									__delay_cycles(5000000);

			uart_puts((char *)"AT+IPR=9600"); // AT commands to initialize gsm modem
			uart_putc(0x0D);
			uart_putc(0x0A);
							__delay_cycles(5000000);

			uart_puts((char *)"AT&W"); // AT commands to initialize gsm modem
			uart_putc(0x0D);
			uart_putc(0x0A);
							__delay_cycles(5000000);
				uart_puts((char *)"AT+CMGR=1"); // AT commands to initialize gsm modem
				uart_putc(0x0D);
				uart_putc(0x0A);
				__delay_cycles(7000000);
			/*	uart_puts((char *) "AT+CMGS=\"0016605415305\""); // 
				uart_putc(0x0D);
				uart_putc(0x0A);
				__delay_cycles(5000000);

				uart_puts((char *) "Sending the Message");
				__delay_cycles(5000000);
			    uart_putc(0x1A);
*/

}

                

  • >     data2[i] = UCA0RXBUF;

    >      i++;
    >     printf("Data%d: %c\n",i,data2[i]);
    This is not displaying the byte you just got, but rather the "empty" buffer entry following it. You probably want to re-order lines 2 and 3 here.
    More generally, putting printf() in your ISR is going to give you misleading results. You may see one of your Rx bytes, but you'll lose the next (at least) 10.
  • Hi Nanda!

    When not receiving data on the MSP432, but transmitting works, the baudrate might to be OK, but I would double check by hooking up a scope to have a look at the waveforms - you're using SMCLK as the USCI's clock source which is not that precise. Maybe it is a bit off and you're just lucky that sending something works.

    Another thing I would test is a loopback of some sent data without having something else connected to the RX line of the MSP - simply try to receive your own data. This does not tell you something about the quality of your clock because it uses the same (maybe inaccurate) timebase, but it shows you if the module is configured properly.

    Dennis
  • Thank you Bruce,

    Moved the printf ahead of the increment.
    Any suggestions instead of printf which i can use ??
  • Hi Dennis,

    I tried sending interrupts from the keyboard and could receive the interrupts so i guess the Rx line of MSP works fine.

    Only problem starts when i hook it with the SIM900 module. I have attached the schematic for your reference.
    exploreembedded.com/.../SIM900.pdf


    Other observations i found :

    1. When USB (U5 connector in schematic) is connected and using putty (baud rate 9600) i can see the response when command AT+CMGR=1 is sent. But when i connect the TX and RX to the MSP432 ( crossed) and ground(SIM900) to ground( MSP432) there is no information in the buffer UCA0RXBUF .

    2. Checked the voltage at D2 ( refer schematic) which is only 4.2V, should this be a problem?? i assume the voltage on the SIM900 module must also be 5V to send the response . I guess this is the reason why USB connection works as 5V is fed from the USB cable. Please correct me if am wrong.

    Please suggest

    Thanks
    Nanda
  • > Any suggestions instead of printf which i can use ??

    As long as your debug-output channel is slower than the events you're debugging (take into account that you're writing >10 bytes for every 1 byte you read), you will not succeed. That said, you can try:

    1) Leave the printf temporarily, ignoring the malfunctions, until you're convinced you're getting the "O" reliably, then remove it and suppose that you will probably succeed from there. This has obvious shortcomings but requires zero effort.

    2) Shorten the debug message -- in the extreme case this just means sending the single byte you received (this is all putty is doing, after all). This is still thin ice, but is an improvement.

    3) Store the Rx bytes in a circular trace array (in memory) and look at the array with the debugger (memory is pretty much guaranteed to be faster than your UART). This is actually easier than it sounds, maybe 20 lines of code.

    4) Send the trace over a second UART which is running much faster (>10x). This is probably a lot of code and has limited long-term utility.

  • Hello Bruce

    Thanks for the suggestion. I shall update the code with the ring buffer to store the received characters. I tried Transmitting the values(string) and receive the same through Rx interrupt. So i guess the board Tx and Rx are working fine.

    I am having problem receiving the values when connection between Tx of GSM and Rx of MSP432 are connected using Tx and Rx pins( it is connected to common ground too).

    Are there any points to consider while considering the connection between TTL of GSM and TTL of MSP432?? 

    Thanks

    Nanda

**Attention** This is a public forum