nstcl wrote on Wednesday, August 08, 2018:
I found that there are several NetworkInterface.c of STM32F7(one included in FreeRTOSV10.0.1, one included in amazon-freertos-1.2.7, one found in this forum posted by Hein Tibosch).
Which one is the newest.
Thank you!
Also, if I set ipconfigZERO_COPY_RX_DRIVER=0 and ipconfigZERO_COPY_TX_DRIVER=0. I can not ping my board.
heinbali01 wrote on Wednesday, August 08, 2018:
The latest non official release of the STM32F driver can be found here
Eventually that will be merged with the official release, once everyone is satisfied with it.
It is expected that you define:
#define ipconfigZERO_COPY_RX_DRIVER 1
#define ipconfigZERO_COPY_TX_DRIVER 1
I should check on an STM32F7 board what happens when a different setting is made, but thanks for reporting.
nstcl wrote on Wednesday, August 08, 2018:
Hi Hein:
I can not open the hyperlink.Could you paste the whole url.
Thank you.
heinbali01 wrote on Wednesday, August 08, 2018:
My bad. Here is the link:
https://sourceforge.net/p/freertos/discussion/382005/thread/5e32c8c6/?limit=250#0b1b
And this is the attachment:
nstcl wrote on Wednesday, August 08, 2018:
Hi Hein:
Thank you.
I have one more question. The offical STM32Cube_FW_F7(which contains stm32f7xx_hal_eth.c) is V1.12.0. Should I replace the stm32fxx_hal_eth.c in the STM32Fxxx_driver.7z with stm32f7xx_hal_eth.c in the STM32Cube_FW_F7_V1.12.0?
heinbali01 wrote on Wednesday, August 08, 2018:
I think there are some essential differences. Please use the unified stm32fxx_hal_eth.c from the 7-zip and the corresponding header files. That should work for both F4 and F7. Please define the correct part as:
#define STM32F7xx 1
Make sure that the header file stm32f7xx_hal_eth.h from STM32Cube does not appear in the include path (-I).
nstcl wrote on Wednesday, August 08, 2018:
Hi Hein:
The ping is ok now!
But the iperf performance is very poor.
E:\target\iperf-3.1.3-win64
λ .\iperf3.exe -c 192.170.1.99 --port 5001 --time 6
Connecting to host 192.170.1.99, port 5001
[ 4] local 192.170.1.198 port 3197 connected to 192.170.1.99 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-6.00 sec 256 KBytes 350 Kbits/sec sender
[ 4] 0.00-6.00 sec 79.9 KBytes 109 Kbits/sec receiver
iperf Done.
The Phy is LAN8720A and its status is 100MBPS fullduplex.
PHY ID 7C0F0
xPhyReset: phyBMCR_RESET 0 ready
$:+TCP: advertise: 01E1 config 1000
prvEthernetUpdateConfig: LS mask 00 Force 1
Autonego ready: 00000004: full duplex 100 mbit high status
The IPv4 stack and iperf configurations are:
ipconfigZERO_COPY_RX_DRIVER ( 1 )
ipconfigZERO_COPY_TX_DRIVER ( 1 )
ipconfigIPERF_TX_BUFSIZE ( 16 * 1024 ) /* Units of bytes. /
ipconfigIPERF_TX_WINSIZE ( 4 ) / Size in units of MSS /
ipconfigIPERF_RX_BUFSIZE ( ( 16 * 1024 ) - 1 ) / Units of bytes. /
ipconfigIPERF_RX_WINSIZE ( 8 ) / Size in units of MSS */
heinbali01 wrote on Wednesday, August 08, 2018:
.\iperf3.exe -c 192.170.1.99 --port 5001 --time 6
Connecting to host 192.170.1.99, port 5001
[ 4] local 192.170.1.198 port 3197 connected to 192.170.1.99 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
Can you start is as the examples in iperf_task_v…c :
iperf3 -c 192.170.1.99 --port 5001 --bytes 100M // from host to device
iperf3 -c 192.170.1.99 --port 5001 --bytes 100M -R // from device to host
Or less than a 100 MB if you want.
The Phy is LAN8720A and its status is 100MBPS fullduplex.
PHY ID 7C0F0
xPhyReset: phyBMCR_RESET 0 ready
$:+TCP: advertise: 01E1 config 1000
prvEthernetUpdateConfig: LS mask 00 Force 1Autonego ready: 00000004: full duplex 100 mbit high status
That all looks OK, also your IPERF settings.
NetworkInterface.c of STM32F7
From the older NetworkInterface/STM32F7 directory? Or from the 7-zip mentioned here above?
Just to be sure, I’ll attach my latest version of the iperf server: iperf_task_v3_0d.c
nstcl wrote on Wednesday, August 08, 2018:
Hi Hein:
The result are:
E:\target\iperf-3.1.3-win64
λ .\iperf3.exe -c 192.170.1.99 --port 5001 --bytes 1M
Connecting to host 192.170.1.99, port 5001
[ 4] local 192.170.1.198 port 3780 connected to 192.170.1.99 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 6.00-6.41 sec 0.00 Bytes 0.00 bits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-6.41 sec 256 KBytes 327 Kbits/sec sender
[ 4] 0.00-6.41 sec 0.00 Bytes 0.00 bits/sec receiver
iperf3: interrupt - the client has terminated
E:\target\iperf-3.1.3-win64
λ .\iperf3.exe -c 192.170.1.99 --port 5001 --bytes 1M -R
Connecting to host 192.170.1.99, port 5001
Reverse mode, remote host 192.170.1.99 is sending
[ 4] local 192.170.1.198 port 3783 connected to 192.170.1.99 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 29.9 KBytes 245 Kbits/sec
[ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 7.00-7.38 sec 0.00 Bytes 0.00 bits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-7.38 sec 0.00 Bytes 0.00 bits/sec sender
[ 4] 0.00-7.38 sec 29.9 KBytes 33.2 Kbits/sec receiver
iperf3: interrupt - the client has terminated
The iperf print info are:
$:Network buffers: 40 lowest 40
vIPerfTask: Received a connection from 192.170.1.198:3779
TCP[ port 3779 ] recv[ 0 ] 37
Got Control Socket: rc -1: exp: ‘’ got: ‘YanLifei-PC.1533718004.618994.6ad249’
TCP[ port 3779 ] recv[ 1 ] 90
TCP skipcount 86 xRecvResult 90
Control string: {“tcp”:true,“omit”:0,“num”:1048576,“parallel”:1,“len”:131072,“client_version”:“3.1.3”}
vIPerfTask: Received a connection from 192.170.1.198:3780
TCP[ port 3780 ] recv[ 0 ] 2957
Got expected client: rc 0: ‘YanLifei-PC.1533718004.618994.6ad249’
vIPerfTCPClose: Closing server socket 192.170.1.198:3780 after 102237 bytes
TCP[ port 3779 ] recv[ 3 ] 1
TCP[ port 3779 ] recv 1 bytes: 0x0C
vIPerfTask: Received a connection from 192.170.1.198:3782
TCP[ port 3782 ] recv[ 0 ] 37
Got Control Socket: rc -1: exp: ‘’ got: ‘YanLifei-PC.1533718014.860579.5a5f56’
TCP[ port 3782 ] recv[ 1 ] 105
TCP skipcount 101 xRecvResult 105
Control string: {“tcp”:true,“omit”:0,“num”:1048576,“parallel”:1,“reverse”:true,“len”:131072,“client_version”:“3.1.3”}
Reverse 1 send 1048576 bytes timed 0: 0
vIPerfTask: Received a connection from 192.170.1.198:3783
TCP[ port 3783 ] recv[ 0 ] 37
Got expected client: rc 0: ‘YanLifei-PC.1533718014.860579.5a5f56’
Network buffers: 40 lowest 39
TX DMA buffers: lowest 2
Network buffers: 40 lowest 38
TX DMA buffers: lowest 1
Network buffers: 40 lowest 37
TCP[ port 3782 ] recv[ 3 ] 1
TCP[ port 3782 ] recv 1 bytes: 0x0C
vIPerfTCPClose: Closing server socket 192.170.1.198:3783 after 43 bytes
vIPerfTCPClose: Closing server socket 192.170.1.198:3779 after 128 bytes
Besides, the FreeRTOS_xx.c of TCP are from FreeRTOSv10.0.1 and the NetworkInterface.c is from the 7-zip mentioned here above.
nstcl wrote on Thursday, August 09, 2018:
Hi Hein:
Thank you for your help.
The IPv4 stack and eth dirver do not work normal with D-CACHE enabled.
When I disable the D-CACHE.It seems working fine now.
Here is the iperf test result with iperf_task_v3_0d.c:
λ .\iperf3.exe -c 192.170.1.99 --port 5001 --bytes 100M
Connecting to host 192.170.1.99, port 5001
[ 4] local 192.170.1.198 port 12461 connected to 192.170.1.99 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 11.0 MBytes 92.3 Mbits/sec
[ 4] 1.00-2.00 sec 11.0 MBytes 92.3 Mbits/sec
[ 4] 2.00-3.00 sec 11.1 MBytes 93.3 Mbits/sec
[ 4] 3.00-4.00 sec 11.0 MBytes 92.3 Mbits/sec
[ 4] 4.00-5.00 sec 11.0 MBytes 92.3 Mbits/sec
[ 4] 5.00-6.00 sec 11.1 MBytes 93.3 Mbits/sec
[ 4] 6.00-7.00 sec 11.0 MBytes 92.3 Mbits/sec
[ 4] 7.00-8.00 sec 11.1 MBytes 93.3 Mbits/sec
[ 4] 8.00-9.00 sec 11.0 MBytes 92.3 Mbits/sec
[ 4] 9.00-9.05 sec 640 KBytes 107 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-9.05 sec 100 MBytes 92.7 Mbits/sec sender
[ 4] 0.00-9.05 sec 99.9 MBytes 92.6 Mbits/sec receiver
iperf Done.
E:\target\iperf-3.1.3-win64
λ .\iperf3.exe -c 192.170.1.99 --port 5001 --bytes 100M -R
Connecting to host 192.170.1.99, port 5001
Reverse mode, remote host 192.170.1.99 is sending
[ 4] local 192.170.1.198 port 12519 connected to 192.170.1.99 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 9.66 MBytes 81.1 Mbits/sec
[ 4] 1.00-2.00 sec 9.80 MBytes 82.2 Mbits/sec
[ 4] 2.00-3.00 sec 9.81 MBytes 82.3 Mbits/sec
[ 4] 3.00-4.00 sec 9.82 MBytes 82.3 Mbits/sec
[ 4] 4.00-5.00 sec 9.83 MBytes 82.5 Mbits/sec
[ 4] 5.00-6.00 sec 9.83 MBytes 82.5 Mbits/sec
[ 4] 6.00-7.00 sec 9.83 MBytes 82.4 Mbits/sec
[ 4] 7.00-8.00 sec 9.81 MBytes 82.3 Mbits/sec
[ 4] 8.00-9.00 sec 9.83 MBytes 82.5 Mbits/sec
[ 4] 9.00-10.00 sec 9.83 MBytes 82.5 Mbits/sec
[ 4] 10.00-10.20 sec 1.95 MBytes 83.0 Mbits/sec
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.20 sec 37.0 Bytes 29.0 bits/sec 4294967295 sender
[ 4] 0.00-10.20 sec 100 MBytes 82.3 Mbits/sec receiver
iperf Done.
heinbali01 wrote on Thursday, August 09, 2018:
Those are perfect results, 92 and 82 % usage of the bandwidth!
When D-Cache was enabled, did you also define NETWORK_BUFFERS_CACHED = 1?
And did you see these comments:
/* Put the DMA descriptors in '.first_data'.
This is important for STM32F7, which has an L1 data cache.
The first 64KB of the SRAM is not cached. */
/* Ethernet Rx MA Descriptor */
__attribute__ ((aligned (32)))
__attribute__ ((section(".first_data")))
ETH_DMADescTypeDef DMARxDscrTab[ ETH_RXBUFNB ];
When using D-Cache, the table DMARxDscrTab is expected to be placed in a non-cacheable memory range.
nstcl wrote on Thursday, August 09, 2018:
Hi Hein：
With NETWORK_BUFFERS_CACHED = 1, there is a error:
NETWORK_BUFFER_HEADER_SIZE is undefined.
heinbali01 wrote on Thursday, August 09, 2018:
Hi Lifei Yan, I’m afraid that the NETWORK_BUFFERS_CACHED option has not been worked out well enough.
I found these definitions for an Atmel CPU:
#define CACHE_LINE_SIZE 32
#define NETWORK_BUFFER_HEADER_SIZE ( ipconfigPACKET_FILLER_SIZE + 8 )
But for a STM32F7 it might not work. I just haven’t had the time to work on it.
I would recommend continuing with your current settings. Later on, I will work out the D-Cache option and come back to it.
Thanks a lot for reporting every thing. By doing so, you have also helped other users
nathanwiebe wrote on Thursday, August 09, 2018:
Are there any plans in the near future to look at the STM32H7 part? It appears that the ethernet MAC peripheral is almost entirely unchanged from the F7, with the only difference that should matter being the DMA peripheral differences from H7 to F7. I have to admit that it is a little beyond me to do the conversion of NetworkInterface.c from F7 to H7 myself, but I hugely appreciate all the awesome work that has been done on the F7 and F4 ports for ethernet, which is working great for me!
heinbali01 wrote on Friday, August 10, 2018:
It is on my list, but I don’t know when I can start on developing a +TCP driver for the STM32H7 part.