Power-on problems with 54455 Fast Ethernet Controller 0 (FEC0)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Power-on problems with 54455 Fast Ethernet Controller 0 (FEC0)

1,646 Views
seckardt
Contributor I

We've been successfully running an application on custom 54455-based boards for months, mainly using revision 1M22H parts.  Some recent boards, using revision 2M22H parts, have been exhibiting power-on initialization problems on FEC0 - while FEC1 is consistently fine.  Even after setting both FECs in internal loopback mode, thereby eliminating the external PHYs from the configuration, FEC0 still doesn't operate properly.  Various types of external resets, however, seem to resolve the problem on FEC0.

 

When FEC0 is not operating properly: there is a valid transmit buffer descriptor queued, TDAR0 is set, the FEC is enabled in ECR0, all interrupts are enabled - but no interrupts are generated and no interrupts are shown as pending in EIR0.  The same application code is used to manage FEC1, and it operates as expected.

 

Does anyone know of any problems specific to FEC0??

Labels (1)
0 Kudos
8 Replies

1,209 Views
tchristoffel
Contributor I

It's possible this sounds like a stupid answer, but, did you properly initialize the FEC0 to GPIO signal matrix?

0 Kudos

1,209 Views
seckardt
Contributor I

The same code consistently works on some of our boards.  And the same code consistently fails on some of our boards after power-up, but consistently works after a subsequent master-reset.  So I believe that we have the register settings correct.

 

However, those GPIO settings are one of the few differences between configuring FEC0 and FEC1.  We only ever see a problem with FEC0; FEC1 always functions properly.

 

0 Kudos

1,209 Views
JWW
Contributor V

seckardt,

 

First I would go ahead and file an SR.

I know on some of our chips that are muxed with GPIO, we leave the input path of the GPIO signals "on" so that the GPIO bank can actually "monitor" the signals.  Could you be getting spurious interrupts on the GPIO pins?  

 

-JWW

 

0 Kudos

1,209 Views
plattro
Contributor I

Hi JWW,

How much does the MCF5445x FEC share common design with the MCF547x/MCF548x FEC design?

 

I'm curious because I am chasing some funny FEC transmit hangs with the MCF5475, so I don't know if the resolution of this issue helps me.

0 Kudos

1,209 Views
JWW
Contributor V

plattro,

 

The 54455 does not really share anything with the FECs on the 547x or 548x family.

The 547x and 548x family have a microcoded DMA engine that handles the transfers (based on a centralized DMA) and none bus mastering ethernets.

 

The 5445x family has a bus mastering FEC and as such does not require the system DMA.  The 5445x family uses the same basic FEC as the 532x and 537x family.

 

JWW

0 Kudos

1,209 Views
seckardt
Contributor I

Our original initialization code ended with the following sequence:

  1. Set ECRn[ETHER_EN] to enable the FEC
  2. Start Rx DMA via writes to ERDSR and RDAR
  3. Start Tx DMA via writes to ETSDR and TDAR

On powerup, this code worked for FEC1 but not FEC0.

 

After switching the DMA start order to Tx then Rx, the code worked for both FEC0 and FEC1.

 

We are still investigating to determine why this change altered FEC behavior.

0 Kudos

1,208 Views
seckardt
Contributor I

Now I see that an Ethernet Bus Error (EBERR) is being generated at some point.  What causes that error, and exactly what steps are required to recover from it?  (I'm not sure what is meant by "software needs to ensure that the FIFO Controller and DMA also soft reset" in the Reference Manual.)

0 Kudos

1,208 Views
TomE
Specialist II

> What causes that error,

 

Table 26-5. EIRn Field Descriptions (continued)

Ethernet bus error. Indicates a system bus error occurred when a DMA transaction is underway.

 

15.4 Memory Map / Register Definition

A bus error response is returned if an unimplemented location is accessed within the crossbar switch. See
Section 14.2.5, “SCM Interrupt Status Register (SCMISR).”

 

So it tried to perform a DMA sysle and it didn't work. Check SCMISR (probably only works for CPU access faults though).

 

So either ERDSRn or ETDSRn weren't set up properly when the Ethernet was enabled, or there was a bad address in one of the Receive or Transmit Buffer Descriptors. Maybe you forgot to set the "Wrap" bits in the rings and it walked off the end.

 

Maybe the rings aren't in uncached memory, or they are and the cache isn't being flushed properly before the ethernet controller starts reading them. Are the BDs in SRAM or SDRAM? Is RAMBAR set up properly (with BDE) if using SRAM? How about the crossbar switch settings?

 

Tom

 

0 Kudos