GSM MODEM INTERFACE

Are you certain that the modem is actually returning what you expect when connected to your microcontroller? How have you proved it?

Without seeing your code, we can only suggest possibilities for losing data, eg:

Your code is grossly inefficient, and can't keep up (even at 48MHz);

If your code is interrupt-driven, you are ignoring and/or disabling interrupts;

If your code is polled, you are just polling at the wrong time;

You might be receiving the characters correctly, but not copying correctly to your buffer;

You might be receiving the characters correctly and correctly copying to your buffer, but then reading incorrectly from the buffer;

etc, etc...

Are you certain that the modem is actually returning what you expect when connected to your microcontroller? How have you proved it?

Without seeing your code, we can only suggest possibilities for losing data, eg:

Your code is grossly inefficient, and can't keep up (even at 48MHz);

If your code is interrupt-driven, you are ignoring and/or disabling interrupts;

If your code is polled, you are just polling at the wrong time;

You might be receiving the characters correctly, but not copying correctly to your buffer;

You might be receiving the characters correctly and correctly copying to your buffer, but then reading incorrectly from the buffer;

etc, etc...

Dear andy,
When i checked it using hyperterminal it responded correctly.I don't have serial analyser to check communication when i send command using uc.

here is the code
; after initialization-

TXREG='A';
while(PIE1bits.TXIF != 1);
PIE1bits.TXIF =0;

TXREG='T';
while(PIE1bits.TXIF != 1);
PIE1bits.TXIF =0;

TXREG=0X0D;
while(PIE1bits.TXIF != 1);
PIE1bits.TXIF =0;

while(PIE1bits.RCIF != 1);
data[0] = RCREG; // i think from here i am
PIE1bits.RCIF = 0; // loosing data.

while(PIE1bits.RCIF != 1); // with gps receiver(based
data[1] = RCREG; // on ARM) i followed the
PIE1bits.RCIF = 0; // the same approach.

means my test routines can not be wrong .I also see disassembly listing carefully.

You missed the instructions on how to post source code - they are really quite clear:
www.danlhenry.com/.../keil_code.png

Maybe there are some other "little details" that you are missing in your project that are causing you trouble...
Attention to detail really is key in this game!

Do you have echo enabled on your modem?
If you do, remember that it may echo the 'A' immediately you send it:

TXREG='A';                  // Send 'A'
while(PIE1bits.TXIF != 1);
PIE1bits.TXIF =0;

                            // Modem echoes 'A' here

TXREG='T';                  // Send 'T'
while(PIE1bits.TXIF != 1);
PIE1bits.TXIF =0;

                            // Modem echoes 'T' here
                            // Already you have a receiver overflow...

What 8051 derivative are you using?

If you're going to do any serious development, you need one!
It doesn't have to be super expensive, but you need it.

In the meantime, you can monitor the transmission or reception using a 'T' connection with hypoterminal, eg:

MCU Tx --------+---------> Modem
               |
               |
               +---------> PC / hypoterminal

Do you have echo enabled on your modem?

Good catch!

I didn't realize he was switching between transmit and receive like that. The normal way to do it is to listen continuously to the modem, which also allows unsolicited messages to be picked up, such as power-on messages, RING, etc.

Definitely go for an interrupt-driven receiver with a ring buffer. It helps a lot.

okey i will definitely use interrupt ......

i am pondering still over a simple question...suppose i transmitted AT<CR> and now clear receive flag so that whatever was echoed from modem (definitely(AT<CR.) is cleared now i must get
1. <CR>
2. <LF>
3. O
4. K
5. <CR>
6. <LF> just after clearing receive i wait for first byte i.e. <CR> as soon as received it is saved in buffer.Now the point is when my uc is completely involved in receiving only what exact difference will be created if i use ISR corresponding to receive interrupt instead of polling. Interrupt are desired when i don'twant to waste my uc's time in just waiting.

From my expereince i know interrupt is always a better choise mut here i don't have any analysis that how these two different approaches will create difference..

"i transmitted AT<CR> and now clear receive flag so that whatever was echoed from modem (definitely(AT<CR.) is cleared"

But how can you be sure that you won't also accidentally clear the first byte of the modem's response?

Your ISR should just put all received characters into a buffer; preferably a circular buffer.

The example in the downloads section does exactly this!

Then your "main" code can scan through that buffer at its convenience.

Instead for sending AT<CR> and then handling the echo, you could send the 'A' and wait for it to be echoed before you send the 'T', etc...

Avoid any attempts to throw away some characters in the middle of an ongoing communication. You will never know if you are close to the reception of the next character, i.e if different runs of the program may result in a character sometimes being received, and sometimes not.

@ Andy and Westermark..
yes now i am going to use interrupts for receive operation definitely...and let you know the results as soon as my ongoing college exams finishes....
you people really give me a new way to think ....
OH! one more thing.. currently i have tied RTS nad DTE to +5 volts(valid RS232 level) to fool my modem that handshaking is provided...do i need to increase this voltage like +9 or +12 volts usually used in RS232...i checked in serial port of my pc and it gives 11.23 volts
at RTS nad DTE...

I take it that this is a normal GSM phone, and not a GSM module for mounting on a PCB?

A GSM module is using TTL levels (probably 3,3V or 5V for all it's signalling). A GSM phone is using RS232 signal levels, since it (at least with the supplied serial cable) is intended to connect to an RS232 port of a computer.

Most newer RS232 devices supports quite low signal levels, to reduce the power needed from battery-driven equipment.

Anyway, if the serial cable has a full set of handshake signals, then you normally can loopback the handshake signals, i.e. you don't have to supply any signal voltage to them. The phone puts out a signal that it is ready - and at the same time, that signal gets sent back into the phone informing it that the other side - you - are also ready. Just like a null-modem cable, but you don't cross the signals from DCE and DTE - you loopback the signals directly in the connector.

Posted a bit early.

Connect RTS to CTS and DCE to DTE on the phone.