Debug Strangeness

[tobiasplayer]

Hi,

 I have an Ethernet socket opened up and an exchanging data between it and my PC. When I have 

"define NPDEBUG         1" defined the data continues to be exchanged but slows down drastically when the UART buffers fall behind and the system is trying to keep up the debug meessages being sent. If I comment out NPDEBUG line, the program blows up after a couple of the message exchanges and starts spewing unreadable junk out to the serial port. Any ideas why turning off debug messaging would cause an issue with a socket?

Thanks,

Bob

[mccPaul]

The debug messages in your previous post imply that the stack is trying to free frame buffers that are already freed. This shouldn't really be happening as you might imagine!

This is most likely to be happening because the same buffer appears more than once on the FECs TX buffer ring. If you haven't modified the NicheLite stack, it may be worth trying to debug the problem by putting a breakpoint on dprintf and tracing back through the call stack when dprintf is called.

So to answer your question - there is no reason why turning off debug messaging should cause a problem with a socket but it may well be that the problem you have occurs much more quickly when the debug messaging isn't chewing up CPU cycles.

Paul.

[tobiasplayer]

Hi Paul,

  Thanks for the response. This stack, or should I say its lack of documentation and examples, is giving me fits. With other stacks I've used you declare a number of socket buffers and then take care not to open more sockets than you've created buffers for. Buffer allocation and deallocation is all done on the fly by the stack not by me.

 You are correct that I am getting messges that already freed frame buffers are trying to be freed, but where do I have control over this? I also went in and commented out the dprintfs that were giving me the messages and I could run I/O in and out of the socket every 5mS for an hour straight without a problem.

  Is there some place to get an example of what initialization needs to be done prior to creating a passive listening socket and then how to correctly open and handle traffic to and from that socket so that I don't have this frame buffer issue?

  Also I see that Freescale used calls to msring for various things within their HTTP server demo when handling socket I/O but I can't find any explanation of the msring calls or when to use them.

Thanks,

Bob

[mccPaul]

Hi Bob,

If I remember rightly, there is a document from InterNiche that explains the programming model of the NicheLite stack on the CD that comes with the board (maybe that's on the CD we had given to us when we went to the Freescale demo, I'll check).

We don't really use the InterNiche stack that much, but I did rewrite the FEC driver to allow us to put very low latency frames onto the Ethernet without the stack getting involved. The problem you are seeing looks like a problem in the InterNiche FEC driver (ifec.c) with the ring of buffer descriptors that the FEC uses for frame transmits and receives.

The stack allocates a ring of two buffer descriptors I believe (look for NUM_RXBDS and NUM_TXBDS) and it may be that you need more. You should be able to tell if the problem is being caused by RX or TX by setting a breakpoint where the debug message is printed and look back through the call stack to see if it's the tx or rx code that fails to free a buffer. When you know, try increasing NUM_RXBDS or NUM_TXBDS (these are #defined in two places btw).

I only suggest this because I had a similar problem and it turned out to be caused by this - in fact, now I come to think of it I think it was caused by a small problem in the FEC tx code that is used to align the frame buffers to a 16 byte boundary. There was a case where there weren't enough tx buffer descriptors available and everything started going sour.

Can't help with msring.

Cheers,

Paul.