>> 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.
|