GSM Modem Transmission Issue

Question

I'm having a problem getting this GSM modem to work with an FPGA (Spartan 3). I've already implemented UART transmission on the FPGA side,the MAX232 to convert TTL->RS232, and 3.3V->5V logic level shifting to interface the FPGA with the MAX232.

I can see the messages sent by the FPGA on my PC (using the Arduino Serial Monitor) with this FTDI Breakout. I can also communicate with the GSM Modem by using the Arduino Serial Monitor to enter the AT command mode and send text messages.

When I send the same message from the FPGA to the modem,however, I receive an empty text bubble on my phone. I've double checked the baud rate settings, the string structure (including a Carriage Return at the end of every text message) and the TX(FPGA)->RX(GSM) wiring order.

I'm still uncertain of why the arduino terminal can communicate with the modem, but the same message sent from the FPGA doesn't transmit to my phone.

UART Settings: 115200 baud, 8 data bits, 1 stop bit, no parity, no flow control.The VHDL UART transmission and 115200Hz clock frequency generator component is shown below for reference.

EDIT: How the modem works:

The modem requires the use of AT commands to it either through SMS or Serial to configure it. I need it to simply send text messages so to do this I have to set the baud rate that the FPGA will use i.e. the default one of 115200Hz and the work mode i.e. SMS. Then exit AT mode and resume transparent mode. See pages 5 and 7 for a description of transparent mode and an illustration of the transmission process

This is done externally to the FPGA with the software that comes with modem to run on a PC. Once the parameters are configured, whenever the modem starts up it will start in transparent mode. So all that has to be done is send your text message and terminate with a carriage return character to signify end of text.

So the modem is in transparent mode and waiting for the text message data when it's connected to the FPGA. The modem does not transmit any data to the host (FPGA/Serial Monitor) when in transparent mode. It only looks out for the text message data in i.e. RX(GSM)

Baud Generator:

 clk_115200Hz : process(clk,reset,clock3_tmp)
        variable a3: integer range 0 to 217;
            begin
                if(reset='1') then
                    a3:=1;
                    clock3_tmp<='0';
                elsif rising_edge(clk) then
                    a3 :=a3+1;
                if (a3 = 217) then
                    clock3_tmp <= not clock3_tmp;
                    a3 := 1;
                end if;
            end if;
         clock3 <= clock3_tmp;
     end process;

Uart Transmit:

  uart_transmit: process (clk,reset)
     variable bit_count: integer range 0 to 9:=0;
     begin
        if(reset='1') then
            tx_line<=idle;
            bit_count:=0;
            TX_DONE<='0';
            elsif rising_edge(clk)then 
                if(enable= '1')then
                    if(TX_READY = '1')then
                     if(bit_count=9)then
                        TX_DONE<='1';
                        tx_line<=idle;
                        bit_count:=0;
                     else 
                        tx_line<=TX_MESSAGE(bit_count);
                        bit_count:= bit_count+1;
                        TX_DONE<='0';
                     end if;
                    elsif(TX_READY = '0')then
                     tx_line<=idle;
                    end if;
              end if;
            end if;
     end process;

Answer 1

The issue was in fact a clock error as pointed out in the comments in my original question. There was a two clock cycle delay from when I pulled the transmission line from low to high to signal the start and then again from high to low to signal the stop (from one of my other entities that was responsible for the TX_READY signal being toggled). Digging up on the manual I found it uses a clock check to determine when its ready to transmit the data to the phone and the delays caused the modem to reset it's buffer and then transmit whatever it received, which because of the delay was nothing.

Thank you to users Sourabh Tapas and Chris Stratton for helping me identify these issues.