Can't write to GSM module through Serial connection from ARM board

Question

In our Graduation project, we're supposed to connect a GSM module (ADH8066) to our ARM board (OK-6410) which is running Embedded Linux (Qtopia) and communicate with it.

When we first operate on the module, it sends a "Ready" message, then we can communicate with it through AT commands. We've communicated with it successfully using Hyper-Terminal and managed to send a simple SMS.

The problem happens when we try to communicate with it from the ARM board.

We manage to receive the "Ready" message, but then we don't have any response.

Here is the code we've developed till now:

int main(void){

int fd;
char *dev ="/dev/ttySAC3";
struct termios options;

char buffer[20];
char buffer2[20];
char *bufptr;
char *bufptr2;
bufptr = buffer;
bufptr2 = buffer2;
int nbytes,nbytes2=0;

fd = open (dev, O_RDWR | O_NOCTTY);

tcflush(fd, TCIOFLUSH);

tcgetattr(fd, &options);

cfsetispeed(&options, B115200); //Set Baud-rate to 115200
cfsetospeed(&options, B115200);

options.c_cflag |= CLOCAL | CREAD; //Enable the receiver and set local mode
options.c_cflag &= ~PARENB; //No parity (8N1)
options.c_cflag &= ~CSTOPB;
options.c_cflag &= ~CSIZE;
options.c_cflag |= CS8;
options.c_cflag &= ~CRTSCTS; //Disable hardware flow control

options.c_lflag |= (ICANON | ECHO | ECHOE); //enable input-canonical mode

options.c_iflag = IGNPAR; //Ignore parity errors
options.c_iflag &= ~(IXON | IXOFF | IXANY); //Disable software flow control

options.c_oflag |= OPOST; //enable output-processing mode

tcsetattr(fd, TCSANOW, &options);

printf("Hello GSM\n");

tcflush(fd, TCIOFLUSH);

//capture the "Ready" message
while(1){
    nbytes = read(fd, bufptr, 1);
    if (0!=strstr(buffer,"Ready")){
        printf("\nReady Found!\n");
        break;
    }
    bufptr += nbytes;
}

tcflush(fd, TCIOFLUSH);

// send simple "AT" AT command
int y = write(fd,"AT\r\n",4);
if (y==4)
    printf("Written\n");

//trying to capture the "OK" response for the above AT command
while(1){
    nbytes2 = read(fd, bufptr2, 1);
    perror ("Read error: ");
    printf("%c\n",*bufptr2);
}

return 1;
}

The response we got is:

Hello GSM

Ready Found!
Written

and then it blocks and stays idle.

If we manage to capture the "Ready" message, doesn't that mean that "read" is working fine? and If "written" is printed above, doesn't that mean that "write" is working fine? So, why can't we communicate with the module?

Thanks.

`tcflush` is, to say the least, destructive. I have a hard time understanding why you want to _discard_ data that's coming from the GSM module. Assuming that this will work comes across as a bit bold. — HonkyTonk, Jun 13 '12 at 15:23
I haven't worked with AT modems before, but I've just had a quick look through the standard - to me it doesn't seem as you're supposed to receive any response when only sending "AT" - does this work in Hyperterminal? Have you tried other commands? — sonicwave, Jun 29 '12 at 16:52

score -3 · Answer 1 · answered Jun 29 '12 at 12:36

-3

you were able to receive "Ready" because modems sends this message without any command. But you start issuing the ATM commands you need to receive the response immediately without any delay because Modem immediately reverts back as soon as you issue the command. Here you need to run two applications one is issue commands and second is to receive the response. Or you can use timer interrupt or reading the serial port response.

answered Jun 29 '12 at 12:36

Nitin Gupta

202
3
9

1

That's just false. Linux will buffer this for you. Running two applications is just a bad idea. – Kristof Provost Jun 29 '12 at 12:48
Agreed with Kristof. I've written plenty of serial protocol applications, and have never had any trouble doing everything in a single thread (or well, not any trouble that could have been fixed by what is proposed in the answer, anyways). – sonicwave Jun 29 '12 at 12:53
Running two applications on the same PC or board is not proposed. Infact, it is just to check out that whether the response is rcvd properly or not. So the user needs to issue cmds from another application and receive the response from the another app so that there could be clear distinction that where the problem is. – Nitin Gupta Jul 02 '12 at 05:12

Can't write to GSM module through Serial connection from ARM board

1 Answers1