I checked but no interrupts are used. I have reshuffled the client code to follow the lwip callback sequence and the issue seems to have dissapeared. Previously, lwip callbacks were used to set flags that were acted upon in a highler level application state-machine. It seemed some race condition may have taken place when doing so.
Thank you for you time/help, Sylvain Email: [email protected] Web: www.siana-systems.com <http://sylvain.siana-systems.com> Tel: (858) 480-7271 "The difficult I do immediately, the impossible just takes a bit longer." -- On Sat, Jan 28, 2012 at 11:22 AM, Kieran Mansley <[email protected]> wrote: > > On 28 Jan 2012, at 19:15, Sylvain Bernard wrote: > > > I've seen a couple old posts on a similar issue but no mentions on a > possible cause/resolution. Any idea? > > > > note: the lwip stack is running in a single-threaded environment (no OS) > > The normal reason for this is that there are two threads running > concurrently in the lwIP core, which causes one of the lists to become > corrupted. But in your case this seems unlikely as you only have one > thread, unless you have interrupts calling directly into lwIP rather than > queuing packets for your main thread to handle. > > Kieran > _______________________________________________ > lwip-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
