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