cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F767 LwIP TCP Client

DziadGarbaty
Associate

Hello,

I'm facing some weird problem that I can't solve myself. I'm trying to get to work a TCP client using LwIP.

Now the weird part:

Everything works just fine in debug mode when I run the program. Connection is being established, and communication works as intended. But when I run the program without debug mode, I get ERR_RTE error.

I searched the internet and couldn't find an answer to my problem.

I suppose the code is fine due to the fact it works in debug mode.

Program generates error in tcp_connect function at netif = ip_route part.

Here is the code:

uint8_t TCP_ClientInit()
{
struct tcp_pcb *tpcb = {0};
err_t res = 0;
tpcb = tcp_new();

if(tpcb != 0) {
ip_addr_t sourceIPAddr;
IP_ADDR4(&sourceIPAddr, 192, 168, 0, 111);
res = tcp_bind(tpcb, &sourceIPAddr, 1500);

ip_addr_t destIPADDR;
IP_ADDR4(&destIPADDR, 192, 168, 0, 15);

res = tcp_connect(tpcb, &destIPADDR, 1400, tcp_client_connected); // this returns error ERR_RTE
}
else {
return HAL_ERROR;
}

if(res == ERR_OK) {
return HAL_OK;
}

return HAL_ERROR;
}

err_t tcp_connect(struct tcp_pcb *pcb, const ip_addr_t *ipaddr, u16_t port,
tcp_connected_fn connected)
{
struct netif *netif = NULL;
err_t ret;
u32_t iss;
u16_t old_local_port;

LWIP_ASSERT_CORE_LOCKED();

LWIP_ERROR("tcp_connect: invalid pcb", pcb != NULL, return ERR_ARG);
LWIP_ERROR("tcp_connect: invalid ipaddr", ipaddr != NULL, return ERR_ARG);

LWIP_ERROR("tcp_connect: can only connect from state CLOSED", pcb->state == CLOSED, return ERR_ISCONN);

LWIP_DEBUGF(TCP_DEBUG, ("tcp_connect to port %"U16_F"\n", port));
ip_addr_set(&pcb->remote_ip, ipaddr);
pcb->remote_port = port;

if (pcb->netif_idx != NETIF_NO_INDEX) {
netif = netif_get_by_index(pcb->netif_idx);
} else {
/* check if we have a route to the remote host */
netif = ip_route(&pcb->local_ip, &pcb->remote_ip); // ### this returns NULL
}
if (netif == NULL) {
/* Don't even try to send a SYN packet if we have no route since that will fail. */
return ERR_RTE;
}  
10 REPLIES 10
bouazizm
ST Employee

Hello @DziadGarbaty ,

During the initialization process, the ETH MAC must be configured with the correct Ethernet link speed and duplex mode after the auto-negotiation process is completed, which can take up to a few seconds (see the API HAL_ETH_SetMACConfig).

To resolve the issue, please follow these steps:

  • With FreeRTOS: Add the task ethernet_link_thread (refer to the example "STM32F767ZI-Nucleo\Applications\LwIP\LwIP_HTTP_Server_Netconn_RTOS" ).
  • Without an RTOS: Add a call to the API Ethernet_Link_Periodic_Handle in your main loop (refer to the example "STM32F769I_EVAL\Applications\LwIP\LwIP_HTTP_Server_Raw").

 

This fix periodically polls the PHY status and updates the MAC configurations if any changes occur to the Ethernet link.

Note: There is no need to add an additional HAL_Delay().

           Both examples can be retrieved in the STM32CubeF7 v1.17.0 package.

Best regards.