Kiran,

The MCF5485EVB board uses a BCM5222 Phy. The BCM5222 has two phy's in one chip, but uses one MDIO port. The MCF5485EVB boad uses only MDIO_0. The coldfire processor supports the option of using two MDIO ports (if you had two phy chips, each with an MDIO port).

I took a look at the FreeScale TX_test code & it looks like the calls to fec_mii_write() & fec_mii_read() are using MDIO_0 for FEC0 & MDIO_1 for FEC1. This would route Phy control data for FEC1 to MDIO_1, which is not connected in the MCF5485EVB board. Thus, FEC1 would not operate properly at the Phy.

If you look at 29.3.4.4 of the MCF548x refrence manual, you will see there are two MMFR registers (for MDIO_0, and MDIO_1). Each of these registers has a Phy Address parameter. So, for the Logic board, you need to use only MMFR_0 (0x9040). Then, select the appropriate phy using that one register. If you would like more information, see section 5 of the BCM5222 data sheet. They give a good description of the media independant interface.

I am not sure exactly what kind of loopback you did, but if you did a loopback from within the FEC, that should work fine since data is not going out the phy & back again.

I suspect this is the problem.

Hope this helps,
Eric Nelson
Logic Product Development

Eric,
Thanks for the response.

I was using FEC loopback mode, just to make sure the Tx part of the driver code is working.

Have you tired to receive the Ethernet packet with either loopback mode ot normal mode?
I was expecting an interrupt or break-point hit whenever I receive the Ethernet packet but no success so far. Also Rx buffer descriptor never gets updated.

Neither FEC loopback nor MII(BCM 5222) loopback mode results in receiving the same packet which I sent by using Tx_text() function !!.

Anyone has the pointer to resolve this issue ?

Thanks in advance,

-Kiran

hhmm, I don't recall ever setting a loopback mode within the FEC or the MII. All of the work I did was looping FEC0 to FEC1 with an external cable pluging the two ethernet ports together. I did not have any issues like you describe using that method.

You probably have already seen this in the tx_test code, but notice, there is no specific interrupt for the FEC recieve. You must ether poll the FEC RX buffer (could possibly drop packets), or use DMA (with the DMA interrupt). (see 29.3.4.1 in MCF5485RM.pdf. You will notice no RX interrupt event)

Also, I have spoke to the folks at freescale. They say they will post an updated version of tx_test soon that does not have the problem you saw.

Eric Nelson
Logic Product Development

Update on the Ethernet issue I had with default tx_test code from Freescale.
As per Freescale,it seems the tx_test code works well with Green Hill software(GHS) tool chain but not with Codewarrior !!. They are trying to fix this issue.

I can't get anything from either FEC using the tx_test code from freescale, and codewarrior. It runs the tests and writes 'test passed' on uart console, but using an ethernet monitor...I see no packets transmitted. It also reports that it ran out of Tx Buffers. I am using CodeWarrior for Coldfire v5. Which version are you using Kiran?

Thanks

I am using code warrior V5 for Coldfire .

Regarding tx_test code;
1. I was under the impression that it is transmitting the packets as the LEDs in my hub was blinking whenever I run the function tx_test()!. But I did not see the packets in my nerwork analyzer !.

2. I ignored the problem and moved on to use the loopback mode (tried FEC loopback and later MII phy loopback). I did not see any packets coming in[see my previous messages] either.

3. As per Freescale, they will be posting the version 1C of FEC code by next week. Maybe the issues we saw is taken care in this revison.


-Kiran

kiran;

did you also notice that you weren't getting any dma or fec0 interrupts? I put breakpoints on all the handlers and they never hit. That seems to be why they run out of Tx buffers pretty fast. I cheked the interrupt masks,etc...and they look right to me. Still trying to figure it out.

-mike augustis
maugustis@aol.com

The problem seems to be that the DMA never gets kicked off the first time. I added this code to tx_test...

//
//
//
volatile unsigned char bMikeDMAdone = FALSE;
void mike_dma_handler(void)
{
bMikeDMAdone = TRUE;
}

//
// Simple DMA test from buffer to buffer. Seems to work fine!
// Uses ALWAYS initiator, which hogs DMA capability. They recommend
// using a timer to pace this if other DMA activity going on.
//
unsigned char from[256];
unsigned char to[256];
//
void MikeTest(void)
{
int i;
u32 flags = MCD_SINGLE_DMA | MCD_INTERRUPT;
u32 initiator = dma_get_initiator(DMA_ALWAYS);
int pri = 7;
int channel = dma_set_channel(initiator, mike_dma_handler);

bMikeDMAdone = FALSE;

/* Enable interrupts in DMA and INTC */
dma_irq_enable(DMA_INTC_LVL, DMA_INTC_PRI);

/* Enable interrupt to the CPU */
asm_set_ipl(0);

memset( to, 0x00, sizeof(to) );

for(i=0; i<256; i++)
from[i] = i;

MCD_startDma( channel,
(s8 *)from,
sizeof(char), // src size addr inc
(s8 *)to,
sizeof(char), // dest size addr inc
sizeof(from), // # bytes to xfer
sizeof(char), // # bytes in each movement
initiator,
pri,
flags,
NULL);

while( !bMikeDMAdone )
;
}

... then called MikeTest after the call to MCD_initDma(). Now I see all the packets transmitted on my sniffer. I still don't really understand why. Hopefully Freescale will have an answer. But in the meantime, this little patch gets the thing going.

-mike

Mike augustis,
As per Freescale, they will be releasing the Version 1C to the public very soon.
I recieved the 1C version from the freescale support member and it is working fine i.e.

1.I see the packets in the network sniffer
2.I get the interrupts/breakpoint hit while transmitting and receiving.
3.FEC Loopback works fine.


-Kiran