MCF5272 Network Driver Problems

[Brett Swimley]

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
>