(Urgent)Inquiries about improving the response speed of device Ethernet communication

joseph05 · ‎2024-01-10

I am developing a device using the nucleo-f429zit6 evaluation board as a reference. This device has an Ethernet communication function, and the Ethernet communication function was tested by directly connecting this device to the server using a cross-Ethernet cable. Currently, after a command is delivered to the device from the server, the response from the device arrives at the server late. As an example, I checked the server's response to a ping command, and the initial response took about 2 seconds. I'd like to know how to improve this response so that it comes out quickly, within 1 second.

The current device's slow Ethernet communication response speed

Below is the clock speed of the hardware used by the device, the firmware version currently being used, and the version of LwIP.

Bob S · ‎2024-01-18

What in blazes is your code doing?????????

OK - more rational thoughts. Check your interrupt priorities. How much code do you have running in interrupt handlers? Note that the HAL "callback" functions are called from the interrupt handlers. Do you have other, blocking, HAL calls in these callbacks? What about HAL_Delay() calls?

Are you using an RTOS? If so, what tasks do you have that are higher priority than the Ethernet task? I don't recall what RTOS priority the ethernet task runs at.

If no RTOS, then something in your main polling loop is starving the LwIP processing calls.

Start disabling portions of your "user" code until you find the culprit.

View solution in original post

belarbi · ‎2024-01-10

Hi, i have the same problem with nucleo144 board, did you found any solution or cause for this delay in response?

joseph05 · ‎2024-01-11

I haven't found a solution yet. stm32f429zit6 is being used in the device under development, and the clock frequency used is 168 MHz. Which MCU do you use and what is the frequency?

Bob S · ‎2024-01-11

That certainly isn't right. I get ping response < 1ms across our internal network using that same Nucleo board. I do see that PC always sends 2 requests before the Nucleo responds. But that is due to the PC (Windows) having a 12us retry timeout. It takes the Nucleo about 500us to respond to pings. I am using the older CubeF4 ver 1.26.1 (not the newer one with the re-designed Ethernet driver).

Can you run wireshark on the host PC? Just to verify there is nothing else weird going on.

What version of CubeF4 and CubeMX are you using? Please don't say "most recent". Can you share/post you .ioc file (you may need to rename it to some file extension other than .ioc in order to post it here).

joseph05 · ‎2024-01-11

Dear Bob S

Below are the CubeF4 and CubeMX versions and the LwIP API type in use.

Cube F4: 1.27.1
CubeMX: 6.9.1
LwIP: 2.1.2
LwIP API in use: Raw API

Due to the nature of the project, it is difficult to share the entire ioc file with the community. I am currently creating an ioc file in STM32CubeIDE, and if there is a part that needs to be reviewed, I can capture that part and share it.

As additional information, the Ethernet cable between the server and the device is tested by using a cross Ethernet cable to directly connect the server and the device without an intermediate device such as a hub, so there is no delay problem caused by the intermediate device.

Piranha · ‎2024-01-11

Your network input processing code assumes that one Rx interrupt means one Rx frame to process, but that is not true.

And also read this:

https://community.st.com/t5/stm32-mcus-embedded-software/how-to-make-ethernet-and-lwip-working-on-stm32/m-p/261456

joseph05 · ‎2024-01-11

Dear Piranha,

Thank you for your interest in this conversation. Your comments are difficult to understand for me, so can you select the content that should be reviewed first?

Dear Bob S

The ping command is used to measure the Ethernet response time of the device. Wireshark is used to share Ethernet transmission and reception communication packets between the server and device. The packet data also contains the results of sending a ping command from the server and responding from the device.

In the wireshark log above, the server's IP address is 192.168.100.121 and the device's IP address is 192.168.100.130.

Bob S · ‎2024-01-11

I don't know how @Piranha knows your code is only expecting 1 packet per IRQ - perhaps from your earlier posts, or he just knows that is how the "new" ST Ethernet code is written (I don't use the new ST Ethernet code). But he might be right - or on the right track. I see NO packets FROM .130 in that wireshark log file. no ICMP responses and no TCP packets. So either you have wireshark filtering and only display/capturing packets from .121 or something is seriously messed up somewhere.

If Pirhana is right, his mention of "your code" is really "the ST Ethernet driver used in your code" (i.e. code ST provided, not something you wrote).

Sorry - I can't be more help than that.

joseph05 · ‎2024-01-18

After disabling LwIP's statistics and debug log output settings, a response to ping was confirmed in about 1 to 1.5 seconds. However, since our goal is less than 0.2 seconds, we are still looking for a solution.

Piranha · ‎2024-01-18

What I said was based on the observation how the old ST code with a broken ethernetif_input() function worked. The Rx packets were piling up in the DMA queue, because the code was not processing those. But it could also be anything from the million issues HAL/Cube broken bloatware has. For example, if you are using RTOS, the Tx deadlock, which is the first issue in the list I gave.

For Wireshark just use a filter "host 192.168.100.130" and it will filter out everything related to that IP address.