Slow ethernet speed in STM32H7xx

[PNaph.2]

Hi All,

We are using the STM32H7 mcu interfaced with ethernet switch LAN9353.

In our firmware application we are using the LwIP network stack and FreeRTOS. And using TCP server-client functionality for communication.

We are able to establish the communication between mcu and external devices via the ethernet switch. The overall communication is ok.

We are reading the PHY registers and according to the speed and duplex mode, we are setting it in the STM32H7 mcu's MAC peripheral. Generally the speed read from the control registers of PHY is 100Mbps full duplex but during the transmission/reception of the packet with the external devices the speed is getting reduced to in range of 8Kbps to 46Kbps.

We have checked the speed by using Wireshark tool and "Task manager->Performance->Ethernet".

Can someone guide us in the above. Is there any way to increase the packet transmission/reception in mcu side or ethernet switch side?

Thanks in advance.

Pratik

[Piranha]

Is the code an absolute junk named HAL/Cube?

What protocols are used?

What code/application is doing the transmission/reception on both ends?

> range of 8Kbps to 46Kbps

Most likely your code is just doing something ridiculous.

[PNaph.2]

>>Is the code an absolute junk named HAL/Cube?\

We are using CubeMx generated code and the HAL libraries, LwIP and FreeRTOS.

>>What protocols are used?

For ethernet we are using the TCP protocol for communciation between server and client. And other protocols like UART, USB, SPI, I2C for other peripherals.

>>What code/application is doing the transmission/reception on both ends?

In our application, the STM32H7 board (as TCP server) is receiving the command packets from the PC application(client) to rotate the motors, drives LED pannel, vacumm pumps and file transfer related commands(transfering the FW binaries to update firmware, image file transfer from camera to PC app, printing barcode images on printer label, error log file ).

After command reception from PC, board will process it, execute it and send the corresponding reply to PC with ACK or NACK.

We have used the memcpy, memset functions, some of the debug logs printing via UART, and some stability delays in our command processing state machine.

We tested the packet transmission and reception only without further processing the it, just receive the packet, at that time the speed was upto 74Mbps.

We also gone through some of the online links for tuning LwIP stack, by modifying the TCP parameters like WND_SIZE, SND_BUF, QUEUE_LEN, and after some tuning the speed is increased up to 200Kbps.

[Pavel A.]

>We tested the packet transmission and reception only without further processing the it, just receive the packet, at that time the speed was upto 74Mbps.

Can this hint that the time is spent in other parts of software that you've mentioned (motors, LEDs etc)?

[Piranha]

> After command reception from PC, board will process it, execute it and send the corresponding reply to PC with ACK or NACK.

I'm guessing, but, as Pavel already said, probably the code is blocking and takes a significant time to complete. If that's the case, the solution is to rework it into asynchronous processing based threads and interrupts.

> some of the debug logs printing via UART, and some stability delays in our command processing state machine

That's, where some additional significant time is spent. And there is no such thing as "stability delays". Broken code must be fixed, not "worked around" by introducing an additional unreliable magic.

[PNaph.2]

Thank you Piranha and Pavel for you response.

>>I'm guessing, but, as Pavel already said, probably the code is blocking and takes a significant time to complete.

We had already removed the blocking STM32 HAL library functions from the application code.

Also, we found some of the links mentioned about tuning methods for LwIP stack to increase TX and RX performance. Also we optimized our application code.

After tuning some of the parameters of LwIP and optimization in the application code the speed is incresed up to 5 times than the previous speed.

[Piranha]

> We had already removed the blocking STM32 HAL library functions from the application code.

That doesn't mean your code is not blocking. What Pavel said, is still true - it's your "further processing" code, that just doesn't transmit/receive faster.

[agallego]

Hello!

I am having a problem with the ethernet speed too. I have managed to speed up the speed of sending the message. However, the module is not able to receive, it does not enter the callback function of the reception. Do you know what could be the cause?

Thank you very much.