Hello,
I'm having trouble using TCP client socket on a PPP link.
I'm using Keil RTX 4.74.0 and MDK-Pro 5.0.4
PPP is established using a GPRS modem (I have updated the Modem_Standard.c to deal with network registration and so on)
In my main loop, once ppp_is_up() == true, I create a tcp_socket using : tcp_soc = tcp_get_socket (TCP_TYPE_CLIENT|TCP_TYPE_FLOW_CTRL, 0, 30, tcp_callback);
and then connect it using : tcp_connect (tcp_soc, rem_ip, 9301, 0);
The server is a http server.
Once the connection is established, the callback is then called from the Core Network with event == tcpEventEstablished. When this event is called, the main loop gets a flag indicating that it's time to write the request to the socket.
The write part is working and I receive a tcpEventACK in the callback.
The server on the other side well receive the request and sends the answer, but, the callback never gets called with the tcpEventData. In the end, the socket is closed and finaly aborted.
I have a serial spy where I can see the PPP dialog and I can see both the request and the answer.
Where do you think I go wrong ?
Thanks,
Alain.
On error, data callback is not called. Most likely the data packet is not received correctly, or some characters are lost in receive direction. Trg a debug library version and check PPP debug messages. If you see CRC errors in the log, then this is the case.
Hello Franc,
Thanks for your answer.
I have put net debug to show me PPP and TCP and it seems that effectively there are some errors. I can see a lot of "PPP-ERR:Frame FCS Check Failed". After having google I have found that it can Frame Check Sequence can have to do with CRC as you mentionned.
046.6 PPP:*** Processing frame *** 046.6 PPP: Length: 1020 bytes 046.6 PPP-ERR:Frame FCS Check Failed
The strange thing is that it always happen, no way to get any data from the socket, only sent data are good on server side.
So, after digging a little in the log I have seen this trace
021.9 PPP:*** Processing frame *** 021.9 PPP: Protoc: LCP 021.9 PPP: Length: 29 bytes 021.9 PPP:*** Processing LCP frame *** 021.9 PPP: Code : Conf_Req 021.9 PPP: Id_Val: 0x03 021.9 PPP: Length: 25 021.9 PPP: Opt ACC-Map: 0x000A-0000 021.9 PPP: Opt PF-Compression 021.9 PPP: Opt ACF-Compression 021.9 PPP: Opt Magic-Num: 0xD78AF494 021.9 PPP: Opt Auth.protocol: 0xC223
The ACC-Map that I suppose to be the Async Control Character Map is marked as if XON/XOFF character should be used but in my configuration PPP_ACCM is defined to 0x00000000 ?
That is what I thought. I suggest you focus on the serial driver. What is the size of your receive buffer? Try to increase the size to 1k. That might help.
If XON/XOFF are marked in character map, that means that XON or XOFF will never appear in data packet. On send, XON is sent as 2 byte sequence, on receive the ESC is stripped off, and original value of XOFF is restored. The more bits you have set in ACCMAP, less effective the data transfer is, but it should work.
Again, thanks for your suggestion.
As I'm using MDK-Pro framework and Cortex M4, this one is using the STM32F4 UART driver. I have "unlocked" the UART_STM32F4xx.c file and updated the __UART1_RX_BUFFER_SIZE (initial value was 128) from 1K to 4K and nothing has changed, still FCS Check Failed.
I have change serial cables that are used between my MCBSTM32F400 board and my modem without success too.
Next thing I will try to do is writing an IP server that would simply send echo to see if the problem has to deal with message length (I doubt about this because I also receive FCS check fail on simple LCP echo command :
641.0 PPP:Sending frame 641.0 PPP: Protoc: LCP 641.0 PPP: Length: 12 641.0 PPP:*** Processing frame *** 641.0 PPP: Protoc: LCP 641.0 PPP: Length: 12 bytes 641.0 PPP:*** Processing LCP frame *** 641.0 PPP: Code : Echo_Rep 641.0 PPP: Id_Val: 0x17 641.0 PPP: Length: 8 641.0 PPP: Magic-Number: 0x367651BD 671.0 PPP:LCP Send Echo Request 671.0 PPP: Magic-Number: 0xD0102765 671.0 PPP:Sending LCP frame 671.0 PPP: Code : Echo_Req 671.0 PPP: Id_Val: 0x18 671.0 PPP: Length: 8 671.0 PPP:Sending frame 671.0 PPP: Protoc: LCP 671.0 PPP: Length: 12 671.0 PPP:*** Processing frame *** 671.0 PPP: Length: 9 bytes 671.0 PPP-ERR:Frame FCS Check Failed 671.1 PPP:*** Processing frame *** 671.1 PPP: Length: 18 bytes 671.1 PPP-ERR:Frame FCS Check Failed 673.0 PPP:LCP Send Echo Request 673.0 PPP: Magic-Number: 0xD0102765 673.0 PPP:Sending LCP frame 673.0 PPP: Code : Echo_Req 673.0 PPP: Id_Val: 0x18 673.0 PPP: Length: 8 673.0 PPP:Sending frame 673.0 PPP: Protoc: LCP 673.0 PPP: Length: 12 673.0 PPP:*** Processing frame *** 673.0 PPP: Protoc: LCP 673.0 PPP: Length: 12 bytes 673.0 PPP:*** Processing LCP frame *** 673.0 PPP: Code : Echo_Rep 673.0 PPP: Id_Val: 0x18 673.0 PPP: Length: 8 673.0 PPP: Magic-Number: 0x367651BD 703.0 PPP:LCP Send Echo Request 703.0 PPP: Magic-Number: 0xD0102765 703.0 PPP:Sending LCP frame 703.0 PPP: Code : Echo_Req 703.0 PPP: Id_Val: 0x19 703.0 PPP: Length: 8 703.0 PPP:Sending frame 703.0 PPP: Protoc: LCP 703.0 PPP: Length: 12
You using UART to communicate with the modem? Have you verified the baudrate?
Note that the modem might be able to accept a larger baudrate error when receiving data from you, than what your side is able to handle when receiving data from the modem.
Next thing - is the UART using DMA or FIFO or similar that helps avoiding character loss in case you get a bit of interrupt latency because of some other interrupt handler consuming too much time or some part of your code turning off interrupts in critical sections?
Got good and bad news : - It's working - Keil's Driver or Keil RLNet gots bug at some points
After digging deep in the source code of the Keil UART Driver : - The UART initialisation is done using a callback that should be called on ARM_UART_EVENT_RX_NOT_EMPTY event. But ARM_UART_EVENT_RX_NOT_EMPTY is never fired in the UART IRQ Processing. - The RLNet PPP is contantly pooling the UART using UART_DataAvailable and UART_ReadData accordingly to the returned available number of data returned.
At some point (don't know when / don't want to spend more time on that issue) the UART_ReadData is called using a 64 byte size request whereas only 1 byteis available in the UART cyclic buufer.
This result in FCS check error (I this RLNet process 64 Bytes where only 1 has been filled ...)
I have solved the problem changing the UART_DataAvailable core function to return 1 whenever ptr_uart->info->rx.empty equal false.
Many thanks for having pointing me in the UART direction.