FW: MCF5272 Network Driver Problems
brett.swimley at aedinc.net
Wed May 1 16:24:02 UTC 2002
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
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
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.
> -----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
> 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
More information about the users