Hi Neil
Here are the results:
1) I added an optional delay at the start of the Ethernet initialization:
FNRESETPHY(); // control the reset line to the PHY to respect any power up delays if required
2) In the case of the M52259DEMO board with MICREL KSZ8041NL I do the following:
#define FNRESETPHY() RESET_RCR |= FRCRSTOUT; fnDelayLoop(11000); RESET_RCR &= ~FRCRSTOUT; fnDelayLoop(200); // > 10ms reset asserted and > 100us before using MIIM
This uses a delay loop that I tuned to be quite accurate for the processor (adapts to the clock speed so that it should always be correct).
This asserts the reset out (could be change to another output pin if desired), waits 11ms and then deasserts it. Then it waits 200us before actually using the MIIM interface.
3) In the case of the M52259EVB with National Semiconductor DP83640 the case is a bit different. This needs a power up delay of 161ms (!!!). I did find that I needed to poll the device quiet a lot of times until it responded the first time that I tested it and now I know why.
In this case I didn't use the loop delay because that's really only intended for short delays for hardware stabilisation during initialization, where values of 10ms or so are acceptably. 161ms is well outside the range that I am comfortable with using this technique, so I delayed the Ethernet task (which performs the initialization) by 200ms rather than the usual 50ms. I also delayed the application task to start up after the Ethernet task (otherwise it may have tried to use Ethernet resources too early).
I use the extern void fnUserHWInit(void) in application.c to assert the interrupt immediately on start up and in the Ethernet configuration the delay define only sets it back:
#define FNRESETPHY() RESET_RCR &= ~FRCRSTOUT;
The RSTO is correct, but there is a catch. the Reset input of the PHY is not attached to it on the EVB, but is attached to the RESET (a push button), which has almost zero delay on power up. Nevertheless the 200ms delay before reading the device does work (perhaps the reset input is not really important but rather the delay before it can actually communicate(?). Therefore I will leave it like this - with the recommendation that the hardware is change to connect the PHY reset to the RSTO - or other port - where possible.
Regards
Mark