On 3/18/2019 9:15 AM, Sergio R. Caprile wrote:
mmm... The bug I mentioned is on the rx side, I see you are losing frames on the tx side. There should be a frame between #4206 and #4207 that is either lost inside your device or on its way to your PC. The same pattern repeats where you mention, there is a missing frame between #4315 and #4316. I would hunt this instead.
To debug this, can you suggest a convenient place in LwIP to record the most recent sequence# transmitted (or at least passed to the dubious driver)?
You don't seem to lose ACKs. The retransmission triggers a bit late for what I like, but as Simon points out, you have an unusual pattern. TCP always wants to wait before sending, if you don't cram its buffer and just sit waiting for the response, it will retransmit when it gets tired of waiting. But if you want to keep sending, it will probably "insist" earlier. As I mentioned before, try a known application. I would chase for those missing frames on the output side, though. You could also check your port is providing correct timing, but I guess we can consider the FreeRTOS port as "standard" and "working" ?
FreeRTOS and timers appear solid; I've got a blinky task that keeps blinking as expected during this nasty pause. The ST-provided glue (driver, FreeRTOS-LwIP-driver binding code), well that's a whole nuther terrible mess... Thanks Sergio, Best Regards, Dave
Cheers _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
-- Dave Nadler, USA East Coast voice (978) 263-0097, [email protected], Skype Dave.Nadler1
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
