Ethernet Speed is not sufficient in STM32F767

vbk22398 · ‎2025-05-11

Presently we are using STM32F767ZI for our ongoing projects. Our application demands high speed data transfer rate through ethernet. We are taking the help of UDP for transfer of real time audio data between 2 STM32F767ZI Nucleo Boards. Further we need to increase the speed of Transmission and Reception of this audio data. So, we seek help for the following information among the community members.

1.

Presently, the HAL Drivers are in polling. Can we convert this HAL Drivers to utilize DMA? Would it make any difference in the speed of Tx and Rx.?

2.
How to increase the speed of LwIP Ethernet in STM32F767ZI? With/ Without DMA!
3.
What parameters decide the speed of data transfer in LwIP middleware that is there in the cube IDE?

mbarg.1 · ‎2025-05-13

Well, this example already use DMA - therefore you can evaluate performances and see how far you are from your target.

Send a flood of packet (what about 200k? packets of 1300? bytes) from a gigabit-capable source (as to say that your source can geerate enough traffic to saturate the 100Mbit interface and is NOT the limit in the test), look at received bytes and packets count, check that the same amount is output, eventually capture on wireshark in and out packet and compare numbers - should be same - and compare to your target.

Share your measurements with us - eventually add a schematic of the layout for make easy to understand to everybody - and we will discuss results.

Eventually you can improve it, but this is nxt step and only if required.

Pavel A. · ‎2025-05-13

@vbk22398 The Ethernet of STM32 already uses DMA. That is its own bus-mastering DMA, and it cannot work in any other way. The polling you see in examples polls for completion of transfer of one packet via that DMA.

Actually your question means, how to eliminate the polling and do something useful in parallel with ETH transfers, like queueing more TX packets or doing other work in parallel.

vbk22398 · ‎2025-05-13

@Pavel A. I understand. Well, there are so many peripherals like UART,I2C,ADC, etc., They don't use DMA naturally or by default. Why, ethernet is having DMA by default and what is the need for the following.

@Pavel A. wrote:
@vbk22398 The Ethernet of STM32 already uses DMA. That is its own bus-mastering DMA, and it cannot work in any other way. The polling you see in examples polls for completion of transfer of one packet via that DMA.

Why do we need DMA with Ethernet?

Andrew Neil · ‎2025-05-14

@vbk22398 wrote:
@Pavel A. there are so many peripherals like UART, I2C, ADC, etc., They don't use DMA naturally or by default. Why, ethernet is having DMA by default

I guess Ethernet is typically handling a lot more & faster data ...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

LCE · ‎2025-05-14

I have used the F767 with lwIP, I think even with the HAL drivers (not using these anymore) the F767 reached 90 Mbit/s with TCP.

So check your code, especially the ETH register settings that set speed and duplex.

Pavel A. · ‎2025-05-14

@vbk22398 ETH has its own DMA because it is a complex module developed by Synopsis. For more information on it please see the buses diagram in the RM and the ETH description (the latter is rather daunting, probably because it has been adapted from 3rd party documentation). Simply put, it ls like a jet airplane uses its main engine also for maneuvering on the ground.

vbk22398 · ‎2025-05-20

Increasing the audio samples in the udp packet increased the speed of the udp transmission. But it made the audio to be more noisy, choppy and didn't give the desired result and we compromised the speed and make some changes in how the audio data was processed. It worked and thanks to @Pavel A. @LCE @Andrew Neil @mbarg.1 for taking time to reply.

LCE · ‎2025-05-20

Don't forget that the other side (probably a windows PC?) can have some terrible latency, so we're using TCP for audio data transfer, with external RAM on the STM32 (H7) side to buffer at least 0.5 seconds of audio data (8 channels at fs = 200 kHz).

And yes, increase packet size to the maximum!

Concerning packet size: I found that my windows PC had a maximum TCP packet size set to only ~1200 bytes or so, that gave LWIP some extra work and time and reduced the data rate, so you might want to check that in the windows registry.

Check this:

Recommended TCP/IP settings for WAN links with a MTU size of less than 576 - Microsoft Support

Look for:

Method 3: Set the MTU size for the network interface manually