GSM MODEM INTERFACE

Your uC seems able to correctly receive characters.

However, your application doesn't seem capable of pickking up and process all received characters.

How have you made sure that you don't loose any received characters?

Are you polling, or do you have an interrupt handler that stores received data in a ring buffer?

Have you made sure that it isn't a printout bug, i.e. that the modem runs at a higher baudrate than your debug printout? Are you using interrupt-driven transmission from a ring buffer when printing out received characters?

I am running uc at 48Mhz so there is no way i can loose data...secondly i store them in array...baudrate is perfectly matched...no print bug because i have tested so many projects and have experience to deal with this kind of silly mistakes....I have tied DTR and RTS to +5v and now i will tie them to +9v to see does it create any difference..although +5 is valid rs232 level...

Of course there are plenty of ways to lose data - even at 48MHz!

There's a lot less excuse to lose data, but it is certainly still possible!

okey can you tell me how i may be loosing data... so that i can make necessary changes...

I asked:

How have you made sure that you don't loose any received characters?

I don't really think "I am running uc at 48Mhz..." is a very comprehensive answer.

Are you polling the serial port, or are both serial ports interrupt driven?

Are you using ring buffers for both serial ports?

What do you mean with perfectly matched baudrate? That you have the same baudrate on both ports? Or that you have checked with an oscilloscope that the actual baudrate matches your expected baudrate?

Are you using printf() or similar for emitting the trace output, or are you just moving the received character to the transmit buffer? And if printf - is it from the ISR or in a main loop?

Right now, we don't have much information - other than your 48MHz setting. We don't even know if you run your serial ports at 1200 baud or at 115400 baud...

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...

@ westermark-
By perfect baudrate match i mean baudrate error can not be an issue because i have checked it on DSO as well as on hypertermianl.My modem communicate at 115200 bps.
I simply transmit AT<CR> and then wait (polling) for receive interrupt to get set.As soon as it get set i read the receive register and transfer this byte into 1-dimensional array location.Now clear the flag and again wait for the next character.

For testing currently i am doing only serial communication.No other task is being handled by uc.So it is less probable that in just clearing flag and saving a byte may result in missing data.

I have given a deeper thought once again and think that may be my modem is using high speed processor this means although baudrate is okey but when it responds i loose some data during flag bit clearing and transferring data.Now trying to get more faster uc.

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.

"Now trying to get more faster uc."

There's no need for that - as you said yourself, a 48MHz processor should be fine:

Instead, use interrupt-driven serial IO.

There are perfectly usable examples in the downloads section...

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

The UART is (at least) single-buffered, i.e. when it has received a character, it moves it to the receive register and then give you a full character transmit time to pick up the receievd character.

8n1 givs 10 bits at 115200 baud (followed by a short pause before the next character) and means that you have at least 90 us to react.

So you pick upp all characters first - and then emit all received characters? That should avoid problems with difference in baudrate between GPS and debug serial port, and time required for whatever method you use to emit the debug info.

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.