Hello Trampas,
The ST provided ethernet drivers for STM32H7 are (were?) buggy, and even more so the lwIP ethernet driver they provided.
This should be common knowledge by now, the internet is full with people having weird problems.
Among other issues, they tell the DMA it can re-use the buffers while lwIP hasn't processed them yet.
(Because they made it zero-copy without understanding what that implies.)
This means that if you are using the DMA buffers directly as pbufs then they may be overwritten if new packets arrive too quickly.
I strongly urge you to check if they fixed these issues in the driver you are using.
Some more details at:
We rewrote the whole lwIP ethernet driver to fix all the issues. We do use cached buffers for DMA, but issue cache
maintenance instructions to make sure everything is okay. (Make sure everything is cache line aligned though!)
We don't use zero copy because we are receiving and sending lots of small packets per second. Copying them as
quickly as possible is much more efficient for memory usage.
Alister also tried to fix all the issues and rewrote the driver too, but with keeping it zero copy I believe:
https://community.st.com/s/question/0D50X0000C6eNNSSQ2/bug-fixes-stm32h7-ethernet
I do not know what the current ST provided driver status is, maybe they fixed everything by now, including the HAL bugs.
If they did then they probably used Alister's code. Our code is rock solid, so I haven't looked at the newest ST code yet.
Best regards,
Indan Zupancic
TT Vasumweg 150 | 1033 SH Amsterdam | The Netherlands
Phone: + 31 [0]20 482 56 32 | Fax: + 31 [0]20 482 00 77 | Email: indan.zupancic@mep-info.com
From: lwip-users <lwip-users-bounces+indan.zupancic=mep-info.com@nongnu.org> On Behalf Of Trampas Stern
Sent: Tuesday, 18 August 2020 17:33
To: Mailing list for lwIP users <lwip-users@nongnu.org>
Subject: Re: [lwip-users] [EXTERNAL MAIL] very poor performance of httpd
So many chips use DMA for the MAC. I had to put the LWIP Pbuf in a non cached section of RAM on an M7 to work. Specifically the M7 data cache was causing problems polling for when DMA was done as DMA wrote to SRAM but the processor was reading the cached version of SRAM. Often when you need to add magical delays or debugging makes a difference it is either a caching problem or volatile data access being done incorrectly.
Trampas
On Tue, Aug 18, 2020 at 11:27 AM Sachs, Nico <nico.sachs@trumpf.com> wrote:
Hi Felix,
I've also got very similar issues with Stm32F7,
It's somehow due to bugs in STMs HAL libraries.
I ended up with a quick fix which just waits a little before the packet gets sent out within low_level_output(...).
I had this one:
//dirty solution
for(uint32_t i = 0; i < 40000; i++) __nop();
/* Prepare transmit descriptors to give to DMA */
HAL_ETH_TransmitFrame(&heth, framelength);
If you access the page with chrome and display developer information, you can see the load times of your page. And there I've seen that after a timeout of 2seconds the files are getting requested again and then it works.
Also use Wireshark to spot what's going on.
This quick fix might not help in your case.
Cheers
-----Ursprüngliche Nachricht-----
Von: lwip-users <lwip-users-bounces+nico.sachs=trumpf.com@nongnu.org> Im Auftrag von Felix Frey
Gesendet: Montag, 17. August 2020 15:41
An: lwip-users@nongnu.org
Betreff: [EXTERNAL MAIL][lwip-users] very poor performance of httpd
Hi,
I've running an application on a STM32F429 using LwIP 2.0.3 and it's httpd.
Basically it works fine, however the performance of the httpd is very poor.
When the browser does a http request for a total of five files (statically linked) with a total amount of 40kB, it takes about 5sec to complete the request.
It seems like the httpd gets stalled.
In the log I can see several of the entrys below:
-----
00006.560: http_poll: pcb=0x2000d7b8 hs=0x2000db08 pcb_state=ESTABLISHED
00006.560: http_poll: try to send more data
00006.560: http_send: hs=0x2000db08 pcb=0x2000d7b8 left=22030
00006.560: Trying to send 0 bytes
00006.560: Sent 0 bytes
00006.560: send_data end.
00006.560: tcp_output
-----
This is repeated every 500ms for about 2sec until sending moves on.
It looks like it simply doesn't anything during this time. Why??
My memory settings are:
#define MEM_LIBC_MALLOC 1
#define MEMP_NUM_TCP_PCB 8
#define MEMP_NUM_PBUF 32
#define TCP_MSS 1460
#define TCP_WND 2920
I've already played with configuration settings, however, it didn't change a lot.
Can anybody explain this behaviour or even help to improve it?
Thanks in advance.
Felix
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users