I think I may have figured out the problem. As I suspected, it was something almost too obvious. I commented out the lines that disable/enable global interrupts in sys_arch_protect() to solve an unrelated problem. I tested the code afterward, and it still seemed to work. Later it quit working due to some other unknown change. I even reverted sys_arch_protect() back to normal, but it still didn't work, probably because of insufficient pbufs. Enabling debugging must have added enough delay to mask it somehow. I guess that's how learning something new goes....
--- On Sun, 8/9/09, [email protected] <[email protected]> wrote: From: [email protected] <[email protected]> Subject: Re: [lwip-users] Delay fixes dropped packets To: "Mailing list for lwIP users" <[email protected]> Date: Sunday, August 9, 2009, 4:17 AM >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
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
