[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Randomly delayed frame (STM32070 package including LwIP

From: stevestrong
Subject: Re: [lwip-users] Randomly delayed frame (STM32070 package including LwIP v1.4.1)
Date: Fri, 28 Dec 2018 15:42:06 -0700 (MST)

Sorry, I corrected the link in my first post over
Here is the correct link to the correct file:

OK, I will try to turn on LWIP_STATS, if this is what you are suggesting.

Meanwhile I made several test and I can only see the problem when the
transmission a of a second file takes place between the requesting a first
file and ACK-ing a (last?) frame belonging to the first file.

Description of Tx frames:
PC: REQ file 1
STM32: PSH+ACK file 1 (part 1)
/[ missing ACK from PC for this part - will come later down ]/
------------------------------------here starts file 2 
PC: REQ file 2
STM32: PSH+ACK + data file 2 (part1)
PC: ACK file 2 (part1)
... (portions of file 2 including all needed frames)
STM32: last frame of file 2
PC: FIN File2
SM32: ACK FIN file 2.
-------------------------------- end of file 2. And then:
/[ continue with ACK for file 1 --- ~40ms after FIN file 2]/
PC: ACK file 1 (part 1)
/[ after 1.9 seconds ! ]/
STM32: last frame of file 1
PC: FIN file 1
SM32: ACk FIN file 1.

Cannot happen that LwIP forgets about (or assigns low prio to) transmitting
that last frameof file 1, and re-deal with it only after seconds?

In your opinion the STM driver eventually does not (or delayedly) receive
the ACK file 1 (part 1) after FIN file 2, right? How can I prove and trace

Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]