lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] LwIP RAW + Zynq - Unresponsive Tx path when Rx is activ


From: Sergio R. Caprile
Subject: Re: [lwip-users] LwIP RAW + Zynq - Unresponsive Tx path when Rx is active
Date: Mon, 13 Aug 2018 10:08:47 -0300
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

Well, the RAW API is tricky and there is no such thing as half-duplex or
unidirectional communications in TCP, so I'd need to see your code.
You should (read: must) be calling sys_check_timeouts() frequently
enough for TCP to handle its internal timers; and since your current
problem is on the send side, I guess you can do with the built-in
handler, that is, no tcp_sent() callback. Do you have one ?
BUT, as Simon said (and more than once), out-of-order packets are mostly
due to driver bugs, particularly DMA drivers.

Please don't paste screen captures, some of us like to scroll the frames
to see what is going on.

Your device is sending something on the 9.82M and suddenly a 9.79M frame
(that should have already been sent but I can't see it because you just
pasted the black and red parts) pops up.
Your client then starts shouting about a previous frame (that should
have already been sent as frame #165377 but I can't see it for the same
reason), I don't have more (read: previous) information, and then
restarts the connection.

To check if a driver is properly working, as in most engineering
endeavours, you have to reduce the number of random uncontrolled
variables to a quantity you can manage. So, instead of your application,
use a known to work good application (read: written by someone with some
expertise on the subject, that is: the example apps in the tree or in
the contrib tree). Since you are debugging a heavy sender, I don't think
the echo is a good candidate, but the web server might be a better
choice. You can also use a bare minimum app that "just sends", but in
that case please send the code so we can check and give you the thumbs
up, otherwise you are debugging your driver and your port and your app
at the same time.
Ruling out the app, then there is your port and your driver.

Another source of errors is people (and vendors) not reading the docs
and calling lwIP low-level functions from different contexts (like main
loop and interrupts on a bare metal system). You said you use RAW API,
and I remember answering some question of yours, but I don't remember if
you are running bare metal or an OS (neither should I).

And sometimes caches... what is it that you have there ?



reply via email to

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