Some random thoughts:
The TX interrupt flag gets cleared by the hardware when the buffer is emptied - which it is by reading it so Reset Flag=NO is correct.

Perhaps you're overflowing the buffer?
When you're "emulating" the GSM-module by sending characters manually from the terminal your sending them quite slowly - if you're sendig them one by one as you are typing them. When you then plugin the GSM-module it'll send the same string (hopefully) at the same baudrate as you did manually but the time between each character is a lot shorter so the time the ISR has to process each character is shorter.

I see that you have a HSEROUT ["Process"] in the ISR, things like that WILL overflow the buffer because your sitting in a loop spitting out the word 'Process' (7 bytes) while more might be comming in. The TX-buffer is only one byte deep so the program will have to put in the 'P' then wait for it to go out, put in the 'r', then wait for it to go out and so. Not untill it has put the last 's' in the Tx-buffer will it continue. In the meantime bytes are still trying to get into the Rx-buffer which is only 2 bytes deep - the buffer will likely overflow.

Now, I see that you've commented the above line out which is good but it illustrates the issue I'm trying to get at perfectly.


Also, I'm not sure if it's intentionally but you're resetting the counter (c) each time thru the main loop so if the mainloop startover in the middle of a string it will start overwriting itself. I think that what you want is to reset (c) at the end of DisplayData routine, and possible in the Error routine.

Finally, at the beginning of the program, try inserting a lengthy pause to allow the PIC and the GSM-module to power up properly then make sure the USART buffer is clear and the interrupt flag reset - then enable the interrupt. If the GSM module has an enable input or something tie that to an output on the PIC so you can keep it disabled untill you're ready.

/Henrik.