2024-03-08 03:18 PM
Hi,
I have configured an ethernet application with LWIP and without OS using RAW API, the connection to a server running on a net assistant tool keeps aborting after 19 seconds of running.
With DHCP disabled, the application's ip address is configured to 192.168.3.168, while the server is running with ip address of 192.168.3.40 and port of 5189. The pings to the both ip addresses are OK, the server can be connected from another PC with ip address of 192.168.3.127.
The execution sequence of the code is as below:
tcp_err(pcb, TcpErrorCallBack);
tcp_sent(pcb, TcpSentCallBack);
tcp_recv(pcb, TcpRecvedCallBack);
tcp_poll(pcb, TcpPollCallBack, 10);
tcp_bind(pcb, &localAddr, 0);
err_t err = tcp_connect(pcb, &remoteAddr, remotePort, TcpConnectedCallBack);
The callback function TcpConnectedCallBack() never gets called, and the application has never connected to the server. tcp_poll() is used to execute tcp_connect() every 5 seconds. After the first execution of tcp_connect, all other executions of tcp_connect returns -10 (Conn already established). Sometimes, the first execution of tcp_connect returns -4 (Routing problem). Each time when the first execution of tcp_connect returns ERR_OK,the TcpErrorCallBack gets called with error code of -13(Connection aborted) 19 seconds after its running with following call stack trace:
The tcp_pcb used for tcp_connect has the following contents after the execution of tcp_connect:
When tracking down the execution of tcp_connect, I got this:
It seems there are incoming data packets:
Having done some experiments, I found whether or not I use tcp_poll or tcp_bind, they all do not make difference.
The main.c which includes all the application code attached. The ioc file is also attached.
After 10 hours debugging, I am nearly desperate about this, so please help!
Regards
Chao
E:\SLC\Designs\Software\STM32\TcpF767ZI\Core\Src\main.c
E:\SLC\Designs\Software\STM32\TcpF767ZI\TcpF767ZI.ioc
2024-03-08 03:21 PM
2024-03-08 03:27 PM
The typical print of the execution process:
The ticks are the elapsetime in second since the application starts running.
2024-03-08 10:23 PM - edited 2024-03-08 10:38 PM
I am working on LwIP on a STM32F767 without an OS as well.
I am trying to use UDP. I'm still working on it. Nothing to report yet. Shouldn't be long though.
I would like to use LwIP sockets, because I have used them successfully on other platforms.
Could you do me a favor ? Could you go to Inc/lwipopts.h and change LWIP_SOCKET from 0 to 1 and try to build it ? Mine has about 20 build errors. What happens when you try to build with LWIP_SOCKET set to 1 ?
I'll have a look at your code and post back in a bit.
2024-03-08 10:25 PM
Have you seen this ?
2024-03-08 10:37 PM - edited 2024-03-09 12:24 AM
Please send me your MX_LWIP_Init() file. I want to see what it looks like without dhcp_start(&gnetif). I am using DHCP. I don't want to set up a new project with your .ioc yet.
2024-03-08 10:43 PM - edited 2024-03-08 11:28 PM
Ignore.
2024-03-09 03:50 AM
2024-03-09 06:49 AM
LwIP sockets work great in ESP32. Why could/would they not work well in STM32 ?
Plain sockets are a great way to connect to an http client's web socket.
It's the weekend here. I'll look at your code when I get back to work.
2024-03-09 12:43 PM
This issue is still unresolved, the number of views on this post is over 80, and any suggestions or comments would be highly appreciated.
We successfully ran an LWIP+RTOS http server example on this Nucleo board 2 weeks ago, so the board itself shouldn't have any problem. Today, I checked the code for initialization and that in while(1) loop in main.c against two Cube examples targeted on different boards, I didn't see any difference. I did a reset on LWIP configuration, then disabled DHCP, chose Lan8742 in Platform Settings, enabled LWIP_RAW APIs, and changed nothing else, I got the same result: the server running in a socket tool did not show any new connection, and the F767's Tcp connection was aborted after 19 seconds. I created 2 breakpoints, one at the end of HAL_ETH_Transmit( ), the other at the end of HAL_ETH_ReadData( ), do the following two figures show the SYN packet was successfully sent out and 60 bytes were received?
The comments on tcp_connect( ) explains it as follow:
"If the connection could not be properly established, either because the other host refused the connection or because the other host didn't answer"
Anyone knows which one applies to my case and why?
Chao