MCF5272 Network Driver Problems

[Eric Norum]

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