From your description, it seems like memory beloging to a packet is
being changed after being delivered to your netif->linkoutput function.
Does your MAC support DMA? If so, make sure the pbufs are freed after
receiving a transmit interrupt for the packet. (pbuf_free(p) then must
*not* be called directly in the linkoutput function! Doing so leads to
memory being freed before it is actually transmitted. Thus the next call
to pbuf_alloc will get the same pbuf and may alter the data while the
MAC sends it using its DMA engine.
Simon
JM wrote:
I'm using lwIP on a Stellaris micro, and saw lots of dropped packets.
Upon further investigation, it turns out these packets were failing
TCP checksum. I noticed that if I enabled debugging in the correct
areas, and enough of it, the issue went away. Long story short, after
lots of trial and error I discovered that if I disable debugging and
add a delay of 300us at the very end, before the return, in
ip_output_if(), it fixes the problem. If I decrease the delay, the
problem starts appearing and becomes worse as I continue to decrease
the delay.
The driver for the onboard ethernet controller is from the Luminary
driver library. I don't imagine that a very high percentage of users
here use the same chip I'm using, but generally speaking, any idea
what I can look for; what would cause this? I'm mainly recieving
data. It's streaming audio data so once I initiate it, the stack only
has to ACK.
------------------------------------------------------------------------
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
