This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Controller not able to collect response from GSM Modem

Hello all,

I am trying to send Command from 89S52 Controller to SIM900 GSM Modem

when i am sending command as

"AT" in response my Receive buffer is able to receive all bytes and code is working fine.

if request is "AT"Response is "AT 0X0D 0X0A 0X0D 0X0A OK " -> working fine

but if i send command as “AT+IPR=9600”

then expected response should be same "AT 0X0D 0X0A 0X0D 0X0A OK " but my buffer is not able to collect it.

it is receiving "AT " and after this it is receiving junk characters (in second attempt i tried to make buffer memory dynamically allocated but that is making program more dirty)

GSM is responding correctly (i verified it using hyperterminal), my code is not able to receive it correctly.

/*drivers.c*/


extern int buf_count;
char Rec_buf[10] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

void serial_IT(void) interrupt 4
{
 if (RI == 1)
 {
         /* if reception occur */
   RI = 0; /* clear reception flag for next reception */
   Rec_buf[buf_count] = SBUF; /* Read receive data */

         buf_count++;
         if(buf_count == 10)
         {
                buf_count = 0;
   }
 }

}



void Send_cmd(char *cmd)
{
  while(*cmd != '\0')
  {
   Uart_send(*cmd);
         cmd++;
  }

  Uart_send(0x0D);
  Uart_send(0X0A);

}

void Uart_send(char data_snd)
{
        TI = 0;
        SBUF = data_snd;
        while(TI==0);
        TI = 0;
}



/*application.c*/

int Check_rsponse_OK(void)
{
                int ret_val = 0;
          if(Rec_buf[0] == 'A' && Rec_buf[1] == 'T' && Rec_buf[2] == 0x0D && Rec_buf[3] == 0X0A && Rec_buf[4] == 0x0D && Rec_buf[5] == 0x0A &&  Rec_buf[6] == 'O' && Rec_buf[7] == 'K')
                {
                                port_0_0 = 1;
                                port_0_1 = 0;
                          ret_val = 1;
                }
                else
                {
                                port_0_0 = 0;
                                port_0_1 = 1;
                          ret_val = 0;
                }
                return ret_val;
}


/*main.c*/

void main (void)
{

 int ret_val = 0;

 init_app( );

 Send_cmd(Check_cmd);

do
 {
        ret_val = Check_rsponse_OK();
 }while(ret_val != 1);

 Reset_receiver_Buffer();
 while(1);

}

Parents
  • How buffering of incoming data is performed is totally irrelevant to how the code processes AT commands and AT command responses.

    In this specific case, the OP is doing AT+IPR to change baudrate - which obviously also requires the OP to care about the result of that baudrate change. Changing from strchr() to memchr() isn't going to make much of a difference if the UART is listening at the wrong speed...

Reply
  • How buffering of incoming data is performed is totally irrelevant to how the code processes AT commands and AT command responses.

    In this specific case, the OP is doing AT+IPR to change baudrate - which obviously also requires the OP to care about the result of that baudrate change. Changing from strchr() to memchr() isn't going to make much of a difference if the UART is listening at the wrong speed...

Children
  • Yes sending command to switch baud rate with out of fixing MCU baud rate to receive response is yet another problem but in first place I told him to don’t use string for modem communications as advice not as solution to his problem!(and it was just a Advice generally for modem communication )

  • Let's finish this endless fight.
    Do what you want you will face it soon if you lucky enough.
    And about switching baud rate I think person who switching baud rate by force know the baud rate changing on response according to modem datasheet and fix it!

  • You are confusing arbitrary bytes streams which might contain NUL, with processing and parsing line responses from a modem in command mode. Once you have the data at a line level it's not going to have NUL, CR or LF, and standard library functions are perfectly usable without having to roll-your-own. Modem's don't return NUL in command responses unless their firmware has been written by idiots. In situations where raw byte streams might be returned, they would normally be delimited by a size or escape character, and documented to do such.

    If the posters don't understand the difference between command and data mode, and can't parse data streams, then they have more problems than can be solved here. The problem is most people posting AT Modem questions here are totally clueless with respect to basic programming tasks. Failure to terminate strings, and understand the consequences of that, and the use of library functions goes to competency.