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; //disable output-processing mode

    tcsetattr(fd, TCSANOW, &options);

    printf("Hello GSM\n");

    tcflush(fd, TCIOFLUSH);

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

    tcflush(fd, TCIOFLUSH);

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

    //trying to capture the "OK" response for the above AT command
        nbytes2 = read(fd, bufptr2, 1);

    return 1;

we got this response:

Hello GSM

--- Ready Found! ---
Written: 3

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?


  • 1
    \$\begingroup\$ Can we get links to all associated datasheets? \$\endgroup\$
    – Kortuk
    Jun 12, 2012 at 19:43
  • \$\begingroup\$ I presmse you used Hyperterminal on windows? Windows and Unix have different ideas about line endings. You might try again with a terminal program on your Linux box. \$\endgroup\$ Jun 12, 2012 at 19:50
  • \$\begingroup\$ @Kortuk: OK-6410 -- (arm9board.net/sel/prddetail.aspx?id=348&pid=200) ADH8066 -- (sparkfun.com/products/10138) \$\endgroup\$
    – ElOrabi
    Jun 12, 2012 at 20:16
  • 1
    \$\begingroup\$ RS232 will more-or-less work in one-to-many mode, so you could use your PC to 'sniff' the communication between the ARM board and the GSM. Things get even better when your PC has two serial ports, and you use a program that can show the data received on both ports interleaved. USB-to-serial converters will not be ideal in this situation (they change the timing), but still way better than being blind. \$\endgroup\$ Jun 12, 2012 at 21:13

1 Answer 1


Some things to check:

  • I always get bit when using UART/RS232 with the newline character & carriage return characters. It looks like you're using \r\n for that which may or may not be what the module wants. A cursory check of the module's datasheet didn't turn up anything specifying what it wants. Make sure that's what your sending out in Hyper-Terminal by checking what characters (if any) it appends for you. Go to File>Properties>Settings>ASCII Setup... for your working HyperTerminal session and see what the settings are. It may not be appending any line feeds at all (but I doubt that).

HyperTerm Settings

Sometimes peripherals only want one or the other (either \r or \n). Also, make sure you have coded them correctly for your compiler as some compilers treat string literals & escape characters differently. If you really want to know what's going on, I'd recommend a COM port sniffer (don't worry, this one's actually free). That way you can get down to the nitty gritty of what's being sent to coax the module into working.

  • I'm not sure what the line of code tcflush(fd, TCIOFLUSH); does, but you might try putting one between the read and write in case your UART buffer is getting ruined somehow.

  • Make sure you're on the right UART, there are two UARTs on the part, and one is for sending AT commands, the other is reserved.

  • Slow your baud rate down. Right now you're running at 115200 baud. Try running at 9600 baud. This might help things if there is an issue with noise on the line, which could be a real possibility depending on how you wired it up. The cable from the PC to the modem is pretty well shielded. If your setup is just bread-boarded with different length wire all over the place you could introduce/pick-up noise. Operating at a lower frequency will help reduce those effects.

  • Check for other things like number of stop bits/parity. There are several settings on a UART that a computer may have decided on for you, that your embedded driver may not have. Some common UART settings (besides baud rate) are the number of stop bits & whether or not you use parity bits. If you just used the default settings for creating your HyperTerminal Session, your likely to have the settings shown below. Check the documentation for your HW driver and make sure your processor is doing the same. HyperTerm Control Settings

  • Correct connection of UART signals. You may have been using a cross-over cable (very common), which did the matching of RX/TX pairs for you. Check if your signals are connected as shown below:




If you're getting a similar output as the referenced question them more than likely the baud rate is your problem. Every time that I see an issue where I'm getting repeated characters in that make no sense, it's always a baud rate issue. You get a UART that is trying to sample bits that are coming too fast/too slow for it, which is usually evidenced as repetitive receipt of several of the same character. Sometimes the break in between characters looks like a bit at your baud rate and then the UART begins clocking in the rest of the bits, sampling all highs/lows and out comes repeated funny characters.

I would look at your RX buffer and make sure you're actually getting in the word "Ready". Don't just do a comparison using strstr because that gives you the offset of the position at which the comparison word is found, which in your case, should be 0. If you can, set a breakpoint and view each of the characters to make sure you really got the word "Ready".

Zerioze each of your buffers ( buffer[20] and buffer2[20]) with a known value (for example 0x00) before you start any reads/writes using a for loop and writing that value to each of array elements. That will help you see if the characters in your array are actually changing and you're not just printing what's left in memory when your program starts.

I would try changing the baud rate of the UART RX/TX separately. It looks like you have that ability from your code

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

If you're really convinced you're receiving the "Ready" but transmitting gibberish, then only change the speed of the TX UART. Vary that until your results change. I can't imagine that this part would use different speeds for TX/RX, but I've seen crazier. Overall, check the actual buffer contents using breakpoints, don't just rely on the string comparison functions and you might learn something from that.

  • \$\begingroup\$ - I checked the Hyper-Terminal ASCII settings, they look like the first screen-shot you posted. - tcflush(fd, TCIOFLUSH); is flushing the I/O buffers, I'll try what you said. - I'm using UART0 as mentioned in the datasheet. - I worked with (8N1) and Baud-rate 115200 and No flow control as settings for the Hyper-Terminal and the Module reacted normally and we sent a SMS successfully. \$\endgroup\$
    – ElOrabi
    Jun 12, 2012 at 20:22
  • \$\begingroup\$ If your settings look exactly like my 1st screenshot, then you're not sending any /n characters. Try removing them from your AT command and see if that works. \$\endgroup\$
    – Joel B
    Jun 12, 2012 at 20:35
  • \$\begingroup\$ But while using the Hyper-Terminal, I've to press "Enter" each time I want to send an AT command. \$\endgroup\$
    – ElOrabi
    Jun 12, 2012 at 20:38
  • \$\begingroup\$ Then it is appending the \r (carriage return character) for you. So try sending your AT commands with a "\r" in them, in your example you would send "AT\r" to the part. \$\endgroup\$
    – Joel B
    Jun 12, 2012 at 20:49
  • \$\begingroup\$ I tried it now, nothing happened :/ \$\endgroup\$
    – ElOrabi
    Jun 12, 2012 at 21:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.