MCF5272 Network Driver Problems

[Ian Caddy]

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