Procedure for Restarting FEC

[ynaught]

Can someone provide a procedure for re-initializing the FEC?

I am working on a design with the Coldfire 5270 CPU.  All our OS is homegrown.  This is the first of our products to support 10/100, and full-duplex Ethernet.  I've just isolated a problem we're having; basically if the PHY negotiates half-duplex Ethernet, but your MAC is configured for full-duplex, you will CAUSE collisions (without detecting them).  TCP sortof takes care of the lost packets, but it's a problem.

So when I went to write a routine to change the duplex setting of the MAC (FEC), it surely does that but also (BONUS!) causes the FEC to stop receiving.

Probably the most common solution is to not start the interface until Link is detected, and configure accordingly, then tear down the interface if Link is lost, and repeat.

But, it would be WAY simpler for me if I could just reconfigure the FEC on the fly.  This is what I've got so far:

void FEC_SetDuplex( int SetFull )
{
 MCF_FEC_ECR   = 0; // Immediately disable Enet, aborting Tx packet if in progress.
 
 if( SetFull != 0 ) { // Full Duplex selected
  MCF_FEC_RCR &= ~MCF_FEC_RCR_DRT; // Clear Half Duplex bit
  MCF_FEC_TCR |= MCF_FEC_TCR_FDEN; // Set Full Duplex Bit
 } else { // Half Duplex selected
  MCF_FEC_RCR |= MCF_FEC_RCR_DRT; // Set Half Duplex bit
  MCF_FEC_TCR &= ~MCF_FEC_TCR_FDEN; // Clear Full Duplex bit
 }
 
 MCF_FEC_ECR   = MCF_FEC_ECR_ETHER_EN; /* Enable */
 MCF_FEC_RDAR = 1;
 MCF_FEC_TDAR = 1;
}

I added the TDAR and RDAR lines, not knowing if they'd help or be necessary.  It's possible that something is going wrong elsewhere, but it *appears* as if the FEC stops receiving after this attempt to reconfigure.

[ynaught · Accepted solution]

Once again, I answered my own question before you guys.

Sort of...

In this case it turns out that, despite the documentation in the 5270 manual, that the bits relating to Ethernet Duplex can be changed on the fly, with out disabling the FEC first.  I know because I tried it.

Actually, the TCR does have correct documentation; it says that bits 1 & 2 may only be changed when Enet is disabled (implying that the others may be changed on the fly).  From that, I inferred (hoped) that the duplex bits for RCR were the same.  Seems like they are.