ksz8041 PHY chip for 52259

[mark]

Hi Neil

Note that you can also connect RSTO directly, assuming no other devices will drive the reset line.
This will give it a rest pulse on power-on and can then be asserted by software by controlling the FRCRSTOUT bit in RESET_RCR

Regards


Mark

[neil]

Hi Mark,
  On the processor there is a pin FEC_TXER but I cannot find where it goes on the schematic, it  shows it going to the ethernet bus. Do you have any idea where it goes?

Regards
Neil

[mark]

Hi Neil


The ksz8721bl has this signal.
The ksz8041nl doesn't have it.

Unfortunately I can't say exactly what it does; I think that it is an output from the EMAC and can cause the PHY to transmit errors signals.

I presume that this function is not very important though since it is not available on all PHYs and also not included in the 7-wire MII mode.

It should be possible to use the FEC_TXER pin as general purpose I/O in this case.

regards

Mark

[neil]

Hi Mark,
  Thanks for the reply. I thought I was going mad as I couldnt find this on the Demo schematic, as it was coming from the processor to the ethernet schematic.

Neil

[neil]

Hi Mark,
 Sorry , one more question 

Looking at the 'Stable supply voltage to reset high' value of the ksz8041 chip, it says the power must be stable for a minimum of 10ms before the reset pin goes high. Looking at the 52259 data sheet, its approx 5 clock cycles before the RSTO* goes high, which is not neat 10ms. But I cant find out how long the power has to be stable before the processor starts up. Any ideas?

Neil

[mark]

Hi Neil

You may remember that there was a problem with the power up time of the ATMEL AT45DB SPI FLASH chips (15ms).
The Coldfire powers up and starts very quickly (under 1ms) so it was necessary to add a delay.

If the PHY also requires a stabilization delay it is a good reason for using a port to control its reset line (or command the reset line to assert reset of longer period). There is no delay at the moment in the code so this will need to be added. I will have a look at the spec later and look at adding a similar delay to the start up routine if the PHY needs one (optionally via port or the RSTO output).

Regards

Mark

[neil]

Hi mark,
  Thanks, that will be great.

If the DEV kit connects the reset to the RSTO pin only , how does it it work? If one time the device doesnt come out of reset correctly,then the processor wouldnt be able communicate with it directly, as there is no way to reset it.

Neil

[mark]

Hi Neil

RESET_RCR = FRCRSTOUT; allows the user to assert the RSTO line.
Then RESET_RCR = 0; to deassert, after a delay.

Regards

Mark

[neil]

Hi Mark,
  As the reset would have to be done before utasker talks to the PHY, how is this best performed?

Regards
Neil

[mark]

Hi Neil

As I wrote, I will add an optional delay to the start of the Ethernet configuration (this can then be configured in app_hw_m5223X.h). I noted also that they recommend a 100us delay after reset until the MII communication interface is used.

Regards

Mark

[neil]

Hi Mark,
  Thanks., much appreciated

Neil

[neil]

Hi Mark,
 I am finishing my design of the board, and placing the ksz8041 reset line as same as the demo board, connected to the RSTOUT* (the rstout* actually goes through buffer then to the ksz8041 reset line).

Before sending the board away to be made, I just want to make double sure that this will be toggled for the delay time required before the MII communication interface is used.

Thanks
Neil

[mark]

Hi Neil

I actually integrated the code to do this today and will test it later on. Since I am using a simply while loop to generate the delay I will also be tuning this loop up (the Kirin3 executes code a bit faster from FLASH since it doesn't need the FLASH speculation workaround activated).

I will confirm as soon as I have also ensured that the output control is suitable.

As long as you have nothing else connected on the reset line which can drive it, there is no problem connecting without a buffer as on the DEMO board.

Regards

Mark

[mark]

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