GSM Modem not sending any reply to PIC

any idea??

i will give 2 more try to this....

what is the capacitor at controller side... is it 10Uf .. it should be same at modem and controller side..

if you can get any other modem please try with it once .. different companya

There are 4 cap each of 1uF 63V
I tried changing all to 100uF 35V.
But didnt work

I am now trying another modem....lets c what happens

the max232 standard as per data sheet says you to use cap of value 1uf or 10uf not beyong that.....

same capacitor should be there on both sides

Hi,

If you noted modem has received AT and it has responded OK (in your post 20); modem works well, no need to change it.

However PIC doesn't receive modem response, problem should be there. Check your max232 receiving side to PIC. (give manual input-signal from modem-side of max232 and monitor correct voltage on PIC side)

Did you use this max232 circuit when you connect PIC to PC ?

Hope this helps you,

Hi...
There is a clue, I got while debugging.

At present moment,

I have pull up(10K) to RX and TX pins. Max232 is in circuit.

The PIC is working fine with hyperterminal
Modem is working fine with hyperterminal

When I connect PIC with Modem...

I send "AT\n\r" to modem and receive "AT" which I am displaying on the 16x2 lcd display.

Along with this, I must receive \n\r as an indication that the modem is echoing the commands.
But, I am getting OERR bit high(RCSTAbits.OERR) which indicates that there is overrun error.
So, I am expecting that I am receiving data from Modem but couldnt properly hold it in RCREG.

Can you guide me, what should I do now?

I see you've totally disregarded my previous post (#14) saying to use "\r\n" instead of "\n\r" (some modems work fine with just '\n').
Also, overrun error implies you're not reading RCREG fast enough so the next byte comes and overwrites it. You're not getting "\n\r" because the modem probably responds with "\r\n", as I've been saying all along. (Notice that these are 2 distinct characters encoded as 0x0D and 0x0A, respectively.)

I didnt disregard your post. I have tried with both the options as \r\n and \n\r. In both the cases I am getting the same output. There is no change at all. So, I didnt mention it.

Yes...I am not able to read the RCREG fast enough. I am trying to resolve that only.

Its finally working.
I have received the response from the modem and could successfully display it on the 16x2 display.

Thank you all for the help!!!

it would be fine of you could write here what you did to get the output so that we can also learn about it and if required can help some one anytime

Hi...
Actually, there was a problem with overflow error in Receiving.

When I connected pull ups to PIC, I started receiving proper characters(without pull up it was garbage).

I had used both TX and RX as low priority intr. So, even when I received the data on RX pin as an echo of TX, RX intr was not generated and finally OERR bit was set loosing the response of Modem.
Now, I changed the RX to High priority intr and its working.

I have attached the image where the received data is shown in buffer.

I however have a small problem now and tht is, how to implement FIFO dynamically in Receive intr.
I read about circular buffer, ring buffer but they are very complex. I am scared of it.

Is there any simple solution available for FIFO implementation?

I’ve been implementing circular buffers in all kinds of flavors and purposes for years now and only with positive results. I think you can’t do serious communication without them!
A circular buffer is the best solution for your problem and for your particular case it’s very easy to implement, so there’s nothing to be scared about.

You declare your buffer as a regular array of bytes, and 2 pointers to byte that will point to elements of this array (or you can just use indexes if you don't like pointers). One pointer is for writing bytes in the array (used by the UART ISR, server, producer etc.) and the other one is for reading bytes from the array (used by the main loop, client, consumer etc.).

A) Initialize both pointers to point to first element of the array. The buffer is then empty.
B) On the producer side (ISR):
- write a byte to where the write-pointer points;
- increment write-pointer;
- if it points after the end of the array, you make it point to the beginning (that’s why it’s called “circular”);
- [optional] if it points to one location less than the read-pointer, the buffer is full (you can skip this test and continue by overwriting).
C) On the consumer side (main loop):
- if the read-pointer points to the same location as the write-pointer the buffer is empty, there’s nothing to read;
- otherwise read the byte pointed to by read-pointer;
- increment read-pointer;
- if it points after the end of the array, you make it point to the beginning (that’s why it’s called “circular”).

Of course, all rules for working with interrupts apply here too (volatility, critical resource access etc.), but otherwise there’s nothing much to it, as you can see.

Arthur

you talking about PULL up resisters?? can I see your circuit diagram pls...