FW: MCF5272 Network Driver Problems

[Brett Swimley]

-----Original Message-----
From: Brett Swimley [mailto:brett.swimley at aedinc.net]
Sent: Wednesday, May 01, 2002 10:11 AM
To: 'Artemii S. Ivanov'
Subject: RE: MCF5272 Network Driver Problems


Thanks Artemii,

There is no data cache on the 5272, so this shouldn't be an issue.  I'm
pretty sure that I have enough network buffers defined to support this
operation.

One more thing:
It seems like a timing issue.  If I place some printf statements into the
driver at key locations, the driver works well.

Thanks again for your response.

Brett

> -----Original Message-----
> From: Artemii S. Ivanov [mailto:Artemii.Ivanov at oktet.ru]
> Sent: Wednesday, May 01, 2002 10:00 AM
> To: Brett Swimley
> Subject: Re: MCF5272 Network Driver Problems
>
>
> Hi, Brett!
>
> I'm not sure that it could help you.
>
> I've bringed up RTEMS on PowerQuicc based board with FEC
> (TQM860)
> as I remember there were problems with data cache
> (check out driver code for appropriate rtems_cache_data_flush
> calls at the
> transmitting, and rtems_cache_data_invalidate at receive)
> You could try to disable caching possibilities at all. and check Net
> functionality. Another problem - are you have enough network
> buffers to
> receive/send packets, did you check that FEC mode fit to the
> network one.
>
> Artemii Ivanov
> Oktet Ltd.
>
>
> On Wed, 1 May 2002, 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?
> >
> > I'm not communicating with the PHY on the development board.  It's a
> > Netburner board and I spoke with their technical staff.
> They indicated that
> > I should not need to do anything.  The PHY autonegotiates,
> and appears to
> > set up fine.  I am running Half-Duplex.
> >
> > I'm not using bootp, so I have initialized the board's IP
> address, etc.
> > explicitly per the documentation.
> >
> > Any insights here would be greatly appreciated.
> >
> > Regards,
> >
> > Brett Swimley
> > Sr. Design Engineer
> > Advanced Electronic Designs, Inc.
> > brett.swimley at aedinc.net
> > ph: 406-585-8892
> > fax: 406-585-8893
> > www.aedinc.net
> >
>