lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Sort of OT


From: JM
Subject: [lwip-users] Sort of OT
Date: Tue, 4 Aug 2009 18:36:05 -0700 (PDT)

So I get a configuration that seems to work.  Data streams decently, even though there are a few dropped packets for no reason.  Today I try it again, but it doesn't work like it did yesterday.  It's dropping lots of packets.  I enable lwIP debugging.  Then mysteriously, things start working again.  Hmmmm. 

Disable debugging, clean, recompile, reprogram, doesn't work.  Enable debugging, clean, compile, program, and it works.  WTF?  I try this a few more times to make sure I'm sane.  Why do I always run across the strange problems? 

So I start to individually disable different debugging sections until it breaks the code.  If I have at least TCP_INPUT_DEBUG enabled and happen to have the "right combination" of enabled options to break the code, I see lots of failed checksums.  If it's configured so it happens to work well, no problems on the debug output.

I'm using OpenOCD on Eclipse, Luminary ARM Cortex-M3, and CodeSourcery compiler.  I remember that sometimes OpenOCD refuses to program the micro because "offset breaks required alignment".  So I started using the programming utility from Luminary last week because that never complained, and my firmware worked equally poorly in either case :-)   Well, it seems that the OpenOCD offset error really means something.  Although, sometimes it will program the micro and not complain, but things still won't work.  At least the TCP_INPUT_DEBUG is generating failed checksum errors, so that gives me something to start with.  But, this is unchartered territory for me.  Any tips, tricks, anything I should know?  I thought the compiler is supposed to deal with this?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]