Hi support team
I am using the EK-RA6M4/5 ethernet example project, the FSP is 5.1~5.3. The EP is showing the FreeRTOS and TCP/IP stack. The EP can be found on the renesas official website.
I can't do the TCP/UDP communication when the "Network is up". I found that i must wait 4~7 seconds when the IP assignment is done(No matter the DHCP is enable or disable).
May i know why i need to wait 4~7 seconds even if "Network is up" and is it a normal status?
Attach my project.
Thanks.
upload my project for reference.
Sorry, i do upload the project, but it seems like it need zip format.EK_RA6M5_FREERTOS_TCP_Client._check.zip
Thank you sir.
Please let me investigate further your project and come back to you with feedback.
Best Regards,
IK_Renesas
Hello sir,
After checking your project in more detail. I would say that generally it seems that it is working fine with no issues. After making changes to the network setting so that I would adjust it in my network. I was able to connect and send messages to TCP server and also receive messages from the TCP server.
Regarding the delay please let me inform you that in your code you have left a while loop probably trying to do some ping requests after the IP of the device is resolved.
In general ,after the successful creation of the TCP socket, the client needs some time to be able to connect to the TCP server and start the communication.
What also plays important role is when the TCP server running on the other device is initiated-started and is listening to incoming connections.
If you will check the documentation of FreeRTOS+TCP stack it is mentioned that this API has an optional time out with a default value.
www.freertos.org/.../connect.html
The time that a TCP client needs to connect to TCP server, depends also on what state is the TCP server from the other side if it is already ready to be listening to connections and it is not fixed every time that the client reconnects to the TCP server.
As mentioned in the documentation of the FreeRTOS+TCP stack if the connect operation does not succeed immediately then the calling RTOS task will be held in the Blocked state (so that other tasks can execute) until either the connect request is successful, or the timeout expires.
So please remove from your code first this while loop which seems that you do not need , since the function you have for ping requests is commented. And try to put the connect process in a retry loop until the result you get from the connect API is 0. In your code res=0.
Hope it helps.
Hi IK_Renesas
Thanks for your reply. Yes, the yellow marked code is not used, just for previous testing, it can all be commented.
I followed your suggestions to modify the timeout of socket via FreeRTOS_setsockopt(), as the default timeout is 2000. i have changed the timeout to 5000, 100, 3000,10000. But all the timeout setting are the same result --- pdFREERTOS_ERRNO_ENOTCONN(-128).
static const TickType_t xTimeOut = pdMS_TO_TICKS( 100 );
// 创建一个 TCP 套接字
client_socket = FreeRTOS_socket(FREERTOS_AF_INET, FREERTOS_SOCK_STREAM, FREERTOS_IPPROTO_TCP);
res = FreeRTOS_setsockopt( client_socket,
0,
FREERTOS_SO_RCVTIMEO,
&xTimeOut,
sizeof( xTimeOut ) );
APP_PRINT ("\r\n FreeRTOS_setsockopt res: %d \r\n",res);
FreeRTOS_setsockopt( client_socket,
FREERTOS_SO_SNDTIMEO,
I just want to make the TCP communication when the IP assignment is done.
This cannot be done exactly immediately after the IP assignment as already mentioned.
Generally the TCP as protocol needs some time to wait for a response from the remote host and receive some acknowledgements.
In case of the communication of a TCP client with a TCP server:
1.The client device initiating the data transfer sends a sequence number (SYN) to the server. It tells the server the number that the data packet transfer should begin with.
2.The server acknowledges the client SYN and sends its own SYN number. This step is often referred to as SYN-ACK (SYN acknowledgement).
3.The client then acknowledges (ACK) the server’s SYN-ACK, which forms a direct connection and begins the data transfer.
So you can understand that the way the TCP protocol generally works adds some latency due to the controls it does.
In case you want to avoid these latencies then you could consider using instead of TCP the UPD protocol.
The UDP generally is faster than the TCP however the UDP does not do all the controls that the TCP does and this makes it as a protocol less secure.
Please send me again your code with the changes you made to test.
And if you want to reduce even more the latencies than consider using UDP instead of TCP which is also supported from the FreeRTOS+TCP stack.
IK
Thanks for your detailed explain. i understand the different between TCP and UDP. I used the AzureRTOS NetX, there is no need to call delay function when do the TCP communication and it connects the TCP server very quickly.
Attached my testing code. I found that i don't need to setting the timeout, so i commented them. I call the
vTaskDelay(200); to let the thread to wait 2000 ms, as my tick is 10ms. It is the simple way to make the communication work.
But sometimes the vTaskDelay(200) is not enough, it will encounter connect result with -128 . maybe 300 or more.
If i don't want to call the vTaskDelay(xxx); how can i make the communication work? Can you show me your code for me . thanks.
EK_RA6M5_FREERTOS_TCP_Client._check_240801.zip
Hello again,
The specific error indicates that the socket is not connected:
It does not indicate a timeout in the connection try.
One case that this could happen could be the case that you have already established a successful connection through the socket to the TCP server and when you retry to connect again through the same socket this cannot been done. Since the connection from the TCP server side from the previous try has not been terminated yet. The server needs to disconnect from the previous session with the client, so that when you can retry it can reconnect again through the same socket.
In case it was a timeout it should the connect API should return to you -116. And you would understand the case of the timeout because the application seems to get blocked until the default timeout of the connection expires. So it would report you the return status with some extra delay.
Could you share your example code with tcp client for me, as i have no idea that if i don't call the vTaskDelay(xxx) to make the FreeRTOS_connect() return successful.
I have implemented in the past a demo for a TCP client for RA6M3 board and now I added to this the functionality to receive also messages from the TCP server.
My implementation is different than yours I have a seperate function for creating the TCP socket and connecting to a remote TCP server. And this function is not inside the while(true) loop as in your code.
It is called once, I haven't added any delays just added a number of retries to connect to the TCP server in case the first attempt fails.
As you can see I am both able to send and receive messages from both sides as soon as the connection between TCP client and server is done.
Find the example code here:
4370.tcp_client_ra6m3.zip