>>/ The FW Library bug in the Ethernet IRQ, eating fast packets is fixed./
>So no, this does not seem to be the standard STM issue...
Oh, I see, missed that part. Should we believe the vendor ? (terrified face)
Anyway, here are my 2 cents:
- Frame 16: bad FCS on ARP response from MCU to PC, why ?
- Your DHCP on UDP port 55555, turn it off, just in case, you don't seem to be
using it
- Frame 2094: Yes, 2058's ACK has been seen, but 2057's not. Then, Seq#s jump
at sometimes more than 1460, so some frames were lost, some not.
- Frame 2162(3,5) ARP request is not seen by lwIP, frame loss
You are definitely having an event that triggers frame losses. Where is
it, I can tell.
You said this is a custom board, I had once something like this where
my driver went out of sync with the eth chip by incorrectly reading available
bytes.
Please run known to work code first, this looks to me like an
eth driver problem
- You say you are using tcp_poll() to enqueue data. Don't do that if you aim
for performance, that is just to avoid state machines on connection closures
and some other good stuff, not for streaming data.
You should start sending your data from your tcp_recv() parsing the
request and then keep steady sending from your tcp_sent()
> According to lwip_stats there is no memory leak and no packet drop
Well, lwIP can only count *packet* drops, not *frame* loss.
And memory leak is tricky, is it possible you are freeing a wrong pointer or in
the wrong place ? Try sending and freeing at the same place, that is
tcp_sent(), let tcp_poll() aside for now.
Check the web server or smtp client sending functions.
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
