MCF52233 FEC..

[matbli]

I’m writing a minimal Ethernet driver for the mcf52233 fec. I have noticed that when I configure a transmit buffer descriptor ring with only one descriptor, being the first and last in the ring. Each Ethernet frame that I launch is being transmitted twice by the hardware. When I configure two descriptors in the ring the problem goes away. Only one receive descriptor seams to be no problem. Any comment?

/Mats

[matbli]

Paul,

Thank your! It always hurts to waste valuble RAM even if it is just a few bytes. But I will just have to live with that. :smileyhappy:

Rgds,
Mats

[mjbcswitzerland]

Hi Mats

I can also confirm the behaviour and 2 buffers are necessary to avoid it.
(there are various other posts on the same theme: eg.
http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=1663&query.id=3794#M1...

Regards

Mark Butcher

[mccPaul]

I've submitted this as a technical request (1-351170701) to see if we can get clarification about the minimum number of BDs.

Paul.

[mccPaul]

It seems that this is not expected behaviour, and it will be documented soon.

The workaround is not too demanding, there just needs to be a minimum of two tx buffer descriptors.

It is only neccessary to have two BDs so that the application can produce a buffer descriptor ring that has one BD with its R bit set, pointing to the frame buffer followed by a second with its R bit clear so that the FEC knows when to stop the DMA transfers. The application will need to allocate an additional two bytes for the second BD and it will need to keep track of which BD is the next one to use. This can be done with a simple flag so overall the impact is low.

Cheers,

Paul.

[maczor]

This post is pretty useful as I've been trying to track down the cause of this bug whilst developing on the M52235EVB Dev Kit.  Perhaps this post should be made sticky?

[Ricardo_RauppV]

Hi Matt / Paul

Only to add information about this question, in fact I also understood that 2 tx_bd approaching is pretty enough (I agree..1 would be enough, unless such oversample(?) situation due to ready bit monitoring..) way to accomplisht tx procedure.

I have 5 buffer to transmit and 5 to receive.

At the tx moment I just write the next application_tx_buffer_address (fully built) to tx_bd.address , and as Paul mentioned, the rx buffers requires one rx_bd for each rx_buffer....

I would like to ask you 2 questions

a) When we start the tx transfer, I undesrtood the mac uses the mii bus to load it into  the phy.What imagine if in that exact moment the phy is transfering a received packet to emac.If this tranfer is made by mii, we would have a conflict? if it is made by other bus..ok ...what did you understand about it?

In fact this doubt started when I decide to pool periodically the phy status link bit to monitor it, and so I thought I could corrupt some incoming frames, since I also want use the MII bus

Regards...

Ricardo Raupp

[mccPaul]

Hi Mats,

It sounds like the FEC's RISC engine doesn't update the Ready bit in the TxBD in time to stop the next DMA transfer to the FEC's FIFO. The manual says that:

"After started, the RISC + DMA continues to read and interpret transmit BDs in order and DMA the associated buffers, until a transmit BD is encountered with the R bit equaling 0"

As you only have one DB you require the FEC to clear the R bit before the DMA pump moves to the 'next' BD and reads its R bit. It is not clear if these are synchronous processes so it may not be possible to guarantee that the R bit will be clear when the FEC tests it. I assume that the FEC's data transfer process expects that you configure the start and end of a BD ring, which implies that you must have at least two Tx BDs. As they are only 16 bits long, you don't lose much by having two BDs.

For Rx the situation is different. You supply a BD, the FEC fills it and clears the Empty bit. When the FEC looks at the 'next' BD it sees that it is not empty and so it stops transferring data until the driver writes to RDAR again. This will work as long as your rx buffer is big enough for any received frame.

Paul.