AnsweredAssumed Answered

Problem with slow response from LWIP to incoming data on STM32F7

Question asked by Jeremi Wójcicki on Sep 15, 2017
Latest reply on Feb 6, 2018 by Terje K Wahl

Hi guys,

 

I am developing software for Stm32F7 with ethernet intefrace (nucleo 144 board). I have prepared and compiled LWIP stack with netconn api enabled. I generated configuration files with cubemx using default settings. I start the stack in a separate thread and use a standard TCP/IP code to mirror incoming data (the RTOS echo example):


void EthernetTask(void const * argument)
{
/* USER CODE BEGIN EthernetTask */
LWIP_UNUSED_ARG(argument);

/* initialize LightWeight IP Stack */
MX_LWIP_Init();

/* Create variables needed for servicing a connection */
struct netconn *conn, *newconn;
err_t err, accept_err;
struct netbuf *buf;
void *data;
u16_t len;

/* Create a new connection identifier. */
conn = netconn_new(NETCONN_TCP);

if (conn != NULL)
{
/* Bind connection to well known port number 7. */
err = netconn_bind(conn, NULL, 7);

if (err == ERR_OK)
{
/* Tell connection to go into listening mode. */
netconn_listen(conn);
/* Infinite loop */
while (1)
{

/* Grab new connection. */
accept_err = netconn_accept(conn, &newconn);

/* Process the new connection. */
if (accept_err == ERR_OK)
{

while (netconn_recv(newconn, &buf) == ERR_OK)
{
do
{
netbuf_data(buf, &data, &len);
netconn_write(newconn, data, len, NETCONN_COPY);

}
while (netbuf_next(buf) >= 0);
netbuf_delete(buf);
}

/* Close connection and discard connection identifier. */
netconn_close(newconn);
netconn_delete(newconn);
}
}
}
else
{
netconn_delete(newconn);
}
}
/* USER CODE END EthernetTask */
}

The stack works fine and I can receive data and send it back to the user. The problem is that the reaction time of the stack is very long, in the sense that the echo takes like even 1 second to bounce back to the user. It does not seem that my uC is busy doing anything else, it more seems like the stack waits quite some time before reacting to data. It is even reflected in ping, every second time the answer seems to be coming too late:

 

Reply from 192.168.3.10: bytes=32 time<1ms TTL=255
Request timed out.
Reply from 192.168.3.10: bytes=32 time<1ms TTL=255
Request timed out.
Reply from 192.168.3.10: bytes=32 time<1ms TTL=255
Request timed out.
Reply from 192.168.3.10: bytes=32 time<1ms TTL=255
Request timed out.
Reply from 192.168.3.10: bytes=32 time<1ms TTL=255
Request timed out.
Reply from 192.168.3.10: bytes=32 time<1ms TTL=255
Request timed out.

 

If I send big chunks of data, that fill up the receive buffer (my PBUF_POOL_SIZE is set to 592) the response come immediately (also when I keep sending the data ping arrives every time). To me its seems like the LWIP stack waits for some time to fill up the buffer and if nothing arrives for a certain time (which seems to be quite long to me) then he processes the buffer contents. Is there some configuration option for the LWIP / ETH where this behavior (timeout?!) can be controlled? It would need my device to react on a few ms basis, rather than ~1s one.

 

Thanks,

Jeremi

Outcomes