MCF5272 Network Driver Problems

[Brett Swimley]

Thanks Ian,

Yes, I know that there may be more than one mbuf to be transmitted in a
frame. Supposedly, I'm transmitting them all.  The 5272 supports a ring
buffer of buffer descriptors. I'm using one buffer descriptor per mbuf. I
think that I should be able to use the empty buffer descriptors even while
another frame is being transmitted.  If the ring buffer becomes full, I'm
waiting for a "Frame TX Complete" event to be asserted by the FEC. Then,
I'll retire the buffer descriptors for the last transmitted frame and
continue on.

It's interesting, because the all the MCF5272 code that I've examined to
date transmits an entire frame using one buffer descriptor (Motorola's
example code as well as the uCLinux driver which uses skbufs ).  I'm
beginning to wonder if there is a problem with the 5272 FEC as I've ported
the MPC860T RTEMS driver (which is what I'm working with) and it supposedly
has an almost identical controller.

I might have to get a sniffer running.

Thanks again for your insight.  All comments are appreciated.

Regards,

Brett Swimley

> -----Original Message-----
> From: Ian Caddy [mailto:ianc at microsol.iinet.net.au]
> Sent: Wednesday, May 01, 2002 7:14 PM
> To: brett.swimley at aedinc.net
> Cc: 'Eric Norum'; 'RTEMS'
> Subject: Re: MCF5272 Network Driver Problems
>
>
> Hi Brett,
>
> You probably know this but there is possibly a chain of mbufs
> to be transmitted
> to the NIC, not just one buffer.
>
> Now you say that you wait until the packet is sent before
> returning the mbuf
> chain, are you sure you have tranmitted all the fragments and
> not just the first
> fragment before freeing the chain.  It sounds like this sort
> of problem.  If you
> put printfs in the send_packet function, there will be more
> time before the
> chain is freed for the packet to be transmitted sucessfully.
>
> One way to check this may be to try to get a network sniffer
> that will check for
> runt packets on the wire.
>
> Also, there should be nothing else required to get ping
> working.  It doesn't
> sound like it is your app that would be causing any problems.
>  You could have a
> look at the netdemo app to compare what it does, but it
> sounds like a driver
> issue.
>
> I hope this helps,
>
> Ian Caddy
>
>
> Brett Swimley wrote:
>
> > I suspect that the FEC transmitter has shut down.  I also
> suspect it's a
> > timing issue.  When I place some printf statements to
> diagnose the problem,
> > I can often get the driver running reliably. Changing to
> the optimized
> > (rather than debug) version of the code also seems to
> change the symptoms.
> >
> > I'm using gdb and a modified version of the BDM Driver
> which you and Chris
> > Johns are familiar with.  I've hacked gdb to poll memory
> locations which my
> > console driver uses to allow printfs to go to gdb, rather
> than out a serial
> > port.  Do you suppose that the background BDM reading of
> processor memory
> > could be interfering?
> >
> > I've modeled the code after the 860T driver, hoping to
> minimize any of these
> > types of problems.  I've also gone out and checked the
> ucLinux driver, and
> > it looks like I'm setting things up correctly.
> >
> > I believe that I'm using the network semaphore correctly,
> as I'm using the
> > rtems_bsdnet_event_receive functions (anything else???)
> >
> > I guess I'm wondering if there's anything else the
> application needs to do
> > for responding to pings other than initializing the
> network?  Should I try
> > the netdemo application instead?
> >
> > Brett
> >
> > > -----Original Message-----
> > > From: Eric Norum [mailto:eric.norum at usask.ca]
> > > Sent: Wednesday, May 01, 2002 10:03 AM
> > > To: brett.swimley at aedinc.net
> > > Cc: 'RTEMS'
> > > Subject: Re: MCF5272 Network Driver Problems
> > >
> > >
> > >
> > > On Wednesday, May 1, 2002, at 09:32 AM, Brett Swimley wrote:
> > >
> > > > Hi,
> > > >
> > > > Several Months ago I posted a note regarding some problems
> > > that I was
> > > > having
> > > > with the MCF5272 Coldfire RTEMS Network Drivers that I was
> > > > developing.  I
> > > > was attributing problems to the instruction cache being
> > > enabled, but
> > > > now I'm
> > > > pretty sure that's not the problem.
> > > >
> > > > The MCF5272 Fast Ethernet Controller (FEC) is essentially
> > > the same as
> > > > in the
> > > > MPC860T.  I have taken that driver and modified it
> slightly for use
> > > > with the
> > > > MCF5272.
> > > >
> > > > For testing, initially I just thought that I would ping my
> > > development
> > > > board
> > > > and get the responses.  Once that was working, I'd dive
> into more
> > > > detailed
> > > > stress testing.
> > > >
> > > > My problem is that I am regularly missing ping reponse
> packets.  It
> > > > _appears_ that I get the request consistently, but the
> > > response just
> > > > does
> > > > not go out the door.  My network driver (I believe) follows the
> > > > documentation faithfully.  I have a transmit Daemon
> task that waits
> > > > for a
> > > > START_TRANSMIT event, and then calls a sendpacket
> function for each
> > > > packet
> > > > pulled off the queue.  Then sendpacket function loads
> > > buffer descriptors
> > > > with mbuf data, and then triggers the FEC to transmit the
> > > frame.  The
> > > > buffer
> > > > descriptors are retired when the frame has been transmitted. An
> > > > interrupt
> > > > event is generated by the FEC when the frame has been
> transmitted.
> > > >
> > > > Currently, my test application only initializes the network
> > > stack, and
> > > > then
> > > > my Initialization task deletes itself.  Are there any
> > > issues with this
> > > > type
> > > > of test?  Should I be doing something more?
> > > >
> > > >
> > >
> > > Can you use a debugger to see what state the transmit
> daemon is in?
> > > Check to see if the packet is in the output queue.   If
> so, something
> > > has happened to the transmit daemon.   If not, either the
> > > network stack
> > > hasn't generated the reply or the transmit daemon has sent
> > > the packet to
> > > the FEC which hasn't sent it.
> > >
> > > If the daemon has sent the packet to the FEC, it would
> > > indicate that the
> > > FEC transmitter has shut down for some reason.
> > >
> > > Ensure you're abiding by the rules of holding/releasing
> the network
> > > semaphore.
> > > --
> > > Eric Norum <eric.norum at usask.ca>
> > > Department of Electrical Engineering
> > > University of Saskatchewan
> > > Saskatoon, Canada.
> > > Phone: (306) 966-5394   FAX:   (306) 966-5407
> > >
>
> --
>
> ianc at microsol.iinet.net.au
> Microsol (Aust) Pty Ltd
>
> Phone: (+61) 08 9473 6600
> Fax:   (+61) 08 9473 6699
>
>