Re: [lwip-users] Randomly delayed frame (STM32070 package including LwIP v1.4.1)

[stevestrong]

Sorry, I corrected the link in my first post over
http://lwip.100.n7.nabble.com/lwip-users-f3.html
Here is the correct link to the correct file:
https://drive.google.com/file/d/1NXsqdz7LNC5vTqxyRgvJo_cXhRXczWav/view

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
that?




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