cancel
Showing results for 
Search instead for 
Did you mean: 

LwIP + UDP echo delay?

Alberto Fahrenkrog
Associate II
Posted on July 26, 2017 at 05:23

Hi all,

I'm working on a STM32F7 discovery board. UDP sending data at high rates, as well as debug messages is working fine.

I'm trying to get the UDP echo example workig, and I notice there is a HUGE delay (order of 10s of seconds) for the echo to return. So far what I have:

Using ncat to send string to IP + port.

LED1 toggles when an Ethernet message arrives ('Enter' on ncat). That works fine, as soon as I send the message out the LED1 toggles.

LED2 toggles when the receive function (pointer to in udp_recv) sends out the echo message. Now, when I receive a message, the udp_recv function does not call immediately, and that is were the delay is (I think), between data arrival on the ethernet interface and passing it up to the application. If I wait (order ~ 10 seconds or more) the echo is returned. After 3 or 4 tries, the delay gets much longer.

However, the data is inside the micro, because if I send two consecutive packets from ncat, the first packet gets echoed back, I get stuck waiting on the second echo.

Any ideas? Any settings I might have overlooked? Anyone come across this before?

I'm using STMCubeMX 4.22.

Thanks,

Albert

1 ACCEPTED SOLUTION

Accepted Solutions
Alberto Fahrenkrog
Associate II
Posted on July 26, 2017 at 11:17

I figured it out.

I had taken the  MX_LWIP_Process() function out of the main loop and called it only when an Ethernet packet arrived. Apparently that was enough to throw the system off balance, since all packets were still in the input buffer.

Putting MX_LWIP_Process() into the main loop solved everything.

Cheers,

Albert

View solution in original post

1 REPLY 1
Alberto Fahrenkrog
Associate II
Posted on July 26, 2017 at 11:17

I figured it out.

I had taken the  MX_LWIP_Process() function out of the main loop and called it only when an Ethernet packet arrived. Apparently that was enough to throw the system off balance, since all packets were still in the input buffer.

Putting MX_LWIP_Process() into the main loop solved everything.

Cheers,

Albert