Handling UART debug output can be tricky, especially so it does not impact
other running code. I have mine setup so printf dumps it's output into a
memory buffer fast, no waiting, and then an INT picks up the strs later and
sends them out the UART. That is important so that the printf does not cause a
major delay in code execution hanging at UART speeds.
However if you have a bunch of the LWIP debug sections turned on, you will need
about 16K buffer space. I see LWIP dump out 14K of str data very fast into the
buffer, before the UART even begins to send the first byte out. I ended up
using the 16K USBRAM memory block on my MCU as the UART string buffer area.
Chris.
----- Original Message -----
From: JM
To: [email protected]
Sent: Monday, August 17, 2009 4:05 AM
Subject: Re: [lwip-users] Duplicate sequence numbers
I have the UART setup for debugging output. The kicker with this is
that introducing enough delay by enabling enough debugging, or even if I define
the debug output as a delay, makes some of the problems disappear. I've also
enabled stats and have studied that.
The driver, yeah, my guess is that's where the problem is. It's the
driver provided by Luminary, so I assumed it was well tested, but I'm
questioning this since the actual lwIP code should be stable enough for what
I'm doing.
I have been studying ethernet and TCP/IP for awhile now, so I have the
basics down but am not too fluent in the fine details. Not using an RTOS. I
believe the driver is using lwIP pbufs, and setting pointers to them....lately
I'm realizing I'll have to learn how the code works better to debug
effectively. However, it is nice to know I'm not the only one who has spent
great amounts of time on this!
--- On Sun, 8/16/09, Chris Strahm <[email protected]> wrote:
From: Chris Strahm <[email protected]>
Subject: Re: [lwip-users] Duplicate sequence numbers
To: "Mailing list for lwIP users" <[email protected]>
Date: Sunday, August 16, 2009, 11:24 PM
The descriptions you have given leave too many possibilities.
Ethernet is very complex. There are a zillion potential issues between the
driver, the lwIP configuration, options, and potential RTOS. Not much anyone
can do for you without a lot more details on what your setup is and some
debugging data.
For example, do you have a console/uart setup to output DEBUG
strings? You really need that. Without that you are blind. lwIP has a lot of
stats and debug info that will help you figure out what is going on inside
lwIP. You will need to get fully aquainted with the debug facilities of lwIP.
You mentioned before setting your pbuf size to 256 bytes. What is
the size of your driver/DMA/MAC buffers? They should probably be set the same
to 256 bytes. Depending on how the driver is writtem, it may or may not
support mixed sizes and full fragmentation. Just the driver alone is a really
big Black Box full of potential headaches.
Troubleshooting skills here are a really big plus. Getting lwIP up
and running is not trivial. You have to start at the bottom and build your way
up from there. I found it hard to get very far on this kind of code until I
developed enough understanding of what makes Ethernet tic from top to bottom.
There is a learning curve. You may be on this longer than you expected. I
sure have been.
Hope this helps.
Chris.
-----Inline Attachment Follows-----
_______________________________________________
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
