On 06.04.2018 15:30, Adrian Figueroa wrote:
I am writing a bootloader application that receives data over ethernet
for flashing the processor it runs on. This is implemented on an
STM32F746 running the ChibiOS-RTOS and the HAL drivers that come with
it. Consequently, the netconn-api is used. I run Lwip 1.4.1, because
Lwip 2.X was not yet ported to ChibiOS and I cannot to do it myself.
Lwip is used to implement a simple TCP server. A python TCP client
connects to it and sends a chunk of data (around 200k).
I moved Lwip pools and heap to external SDRAM, so I can store large
amounts of packets without discarding them.
First, the TCP server thread waits for an incoming connection with
“netconn_accept()”. Find this in “server.c”, attached to this mail.
There is also a “helper” thread that cleans things up after a
connection was closed (dynamic threads).
After “netconn_accept()”, the netconn is handed over to a thread that
receives data. Find the receiver functionality in “receiver.c”.
The receiver constantly calls netconn_recv(), until the connection is
closed. A netbuf is filled each time and chained to the previous
netbuf. I also have an evaluation thread that works on the received
netbufs, but it does not do anything at the moment. In the end, I have
a long netbuf chain in memory, ready for evaluation.
The problem is that I lose some of the packets in the process. Find
the dump from Wireshark attached. My lwipopts.h is also included in
the mail. I chose very generous amounts of storage for all pools,
because I have 32 MB of SDRAM available. I get no errors at all in
Do you have any suggestions?
Are you aware that you seem to be using TCP segmentation offloading on
your windows network card? The wireshark trace shows TCP segments with
5840 bytes although MSS is advertised as 1460 by lwIP. If you want (us)
to debug network problems using wireshark, please ensure you change the
driver settings to make wireshark let you see what's on the cable!
lwip-users mailing list