fec tx power up issue

[RobertDaniels]

I've been investigating an issue we're having with our i.MX53 based device.  Essentially what we're observing is that sometimes on some devices when they boot up the fec seems to have issues sending tx packets to the phy.  I wrote a simple loopback test in which I set up the fec for external loopback and enabled the loopback feature on the phy.  I then sent out 20 packets and watched for the packets on the rx.  With this test I see that when the device boots into this bad state I don't get all the packets.  I believe it's a tx issue since I have also tried pinging another computer and I've observed that some packets just don't ever make it.

It seems odd that I don't see this problem on all devices, just some.  And it doesn't happen every time they power up.  Some devices seem to have this problem 10% of start ups, while others are less.

Has anyone experienced this issue or have any ideas of where to look?

I'm currently using the 3.14 kernel with rmk fec patches.  I've experienced this same issue in the 2.6.35 kernel as well.

Thanks!

[fabio_estevam]

Could this be related to: "ERR007080 LDO: On-chip LDO regulators may not enable or have a delayed output on power up" described in the mx53 errata doc?

[igorpadykov]

Hi Robert

this may be hardware issue, for example incorrect power-up

sequence or bad DDR. Also any powered device, attached to processor,

before processor powers up, may cause weird behaviour.

Could you recheck this issue on Freescale QuickStart Board ?

Does this happen for example using OBDS (without OS) ?

On-Board Diagnostic Suit for the i.MX53 Quick Start Board :

----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

Best regards

chip

[RobertDaniels]

chip,

I'm not sure testing on the QSB will yield much information because we don't see this on all our boards, just some (~30%), and we only have one QSB.

The DDR seems to be operating correctly, and we've verified that our powered devices are not powered up before the processor.

We are following the power-up sequence as specified but we've definitely run into issues with the reset circuitry.  It seems a bit touchy and we've had to allow for a three second delay on power-up to ensure that the processor power has drained completely before starting up due to reset issues.

On a possibly related note, I've also run into a problem on start-up where the kernel gets stuck initializing the mmc.  We have an emmc chip on our device and I've seen that sometimes on start-up the card inserted bit is set on interrupt (which normally is not set) and the mmc driver is never able to clear it so the interrupt continuously happens, locking the kernel.

Robert

[igorpadykov]

Hi Robert

you should verify that all board power supplies

(capacitors) are fully discharged (<0.2V) before board will

power-up. Next, POR should be sufficient duration, so

all power supplies and crystals (24MHz, 32.768KHz) clocks

become stable, before POR released.

Otherwise you will see these and probably find more

very weird effects.

Best regards

chip

[RobertDaniels]

Chip,

I implemented a loopback test that puts the phy into loopback mode.  This test looks for dropped packets.  When my board boots up normally, the test passes, but when it's bad the test fails.

Does this help identify where the problem lies?

Robert

[igorpadykov]

Hi Robert

please implement all suggestions given you before,

this definitely will help "identify where the problem lies".

Probably most fast way - just to resolder bad boards:

change processor or fec chip (LAN8720).

Best regards

chip