µTasker Forum

µTasker Forum => NXPTM M522XX, KINETIS and i.MX RT => Topic started by: neil on January 26, 2009, 05:20:06 PM

Title: ksz8041 PHY chip for 52259
Post by: neil on January 26, 2009, 05:20:06 PM
Hi Mark,
  Just wondering if you can give me your thought on this, as I have never dealt with a PHY chip before. The demo kit has the KSZ8041NL , but I can only get the KSZ8041TLI part. The only difference I can see is that the TLI part also does SMII interface, package type, and about £1 more expensive. Apart from that is looks compatible , all registers numbers in the NL are the same as the TLI, the only thing the TLI has a couple of extra registers for cable diagnostics. 

Thanks very much for your help
Regards
Neil

Title: Re: ksz8041 PHY chip for 52259
Post by: mark on January 26, 2009, 07:01:52 PM
Hi Neil

Check also the KS8721 or the Davicon DM9161AE.
Basically all PHYs have a standard set of registers and so are basically interchangeable. Therefore all will be OK for normal Ethernet connectivity.

The differences are in the additional features that they support (like auto crossover or IEEE I588 PTP capability in the Nat-Semi DP83640). If the extra features are not activated they all look much the same.

Regards

Mark

Title: Re: ksz8041 PHY chip for 52259
Post by: neil on January 26, 2009, 07:34:06 PM
Hi Mark,
  Thanks for your help . I managed to get 22 of the KSZ8041TLI part, so will use this. I had a look at the DEMO kit that uses this, and noticed the reset pin only seems to go to the edge connectors, and doesnt have any pullups, so going no where.  I fully understand that really this is not a utasker issue, but any help is really great.

Regards
Neil
Title: Re: ksz8041 PHY chip for 52259
Post by: mark on January 26, 2009, 09:35:44 PM
Hi Neil

See whether there is an internal pull up on the reset line.

If you do have a spare port which can be used to take the PHY out of reset it is a good idea to use it to control this.
The PHYs have weak internal pull-ups and pull-downs on several 'STRAP' inputs which define its mode on reset. These share other lines and sometimes these have to be connected to the processor which may have a weak internal pull-up. In this case it is not always sure which state the configuration gets.

See following: http://www.utasker.com/forum/index.php?topic=161.0

When the processor can control the reset it can:
a) hold the PHY in reset
b) set the lines temporarily as outputs and drive the required state
c) allow the PHY to come out of reset
d) set the pins back to MII mode


Also external resistors do the trick but the SW version is more flexible.

Regards

Mark
Title: Re: ksz8041 PHY chip for 52259
Post by: neil on January 26, 2009, 10:30:41 PM
Hi Mark,
  Do you recommend controlling all STRAP inputs with the processor?
 
  Is it okay to drive the KSZ8041TLI strap inputs and RESET pins directly from the processor pins?

Regards

Neil
Title: Re: ksz8041 PHY chip for 52259
Post by: mark on January 26, 2009, 11:05:40 PM
Hi Neil

It depends on the PHY chip.

The inputs which share with the MII interface are the ones to watch (they are already connected to the processor because you have no choice). The others can be strapped in HW.
As long as you can communicate with the PHY via the serial bus (the ones muxed with IRQ3 and IRQ5) you can then overwrite most strap settings - on order to communicate, you need to ensure that you know the PHY address, which is strapped. If it is strapped via a line which is not well defined (the ones discussed earlier) you can either ensure it by driving (as discussed earlier) or else scan all possibilities until the used address has been found (I have done this on the M52259EVB because there seems to be a pull-up/pull-down issue on its address strapping lines (although it still seems to get 0x01 as value - but best to be safe).
Some PHYs may also need a delay (not the Micrel ones as far as I know and have experienced) before they are ready in which case they can be polled until a register read returns the expected value.

regards

Mark
Title: Re: ksz8041 PHY chip for 52259
Post by: neil on January 26, 2009, 11:55:08 PM
Hi Mark,
  As I never have used an PHY directly before there are a few things Im not sure about.

1. Looking at the 52259 manual,is the MII the interface for setting up the PHY?
2. What actual pins to I need to have HW pulldown/up etc?
3. How do I communicate with the device when setting it up?

I have attached the strapping inputs.

Regards
Neil
Title: Re: ksz8041 PHY chip for 52259
Post by: mark on January 27, 2009, 11:10:17 AM
Hi Neil

The MII interface has two parts.
- The communication part with is effectively interfaced via the M52259 ports TI and TJ
- The maintenance channel (a two wire bus like an SPI) interfaced on pins IRQ3 and IRQ5. This is optional and always reading and writing to PY internal registers.

You need pullups/down only on the strap inputs. However if you read the PHY details about these pins you will find that they usually have weak internal pullups/downs to set the most usual settings (eg. MII mode, auto-negotiation).
Compare with the M52259DEMOCOM diagram where the straps have all been externally pulled up/down (maybe some could be spared?)
The KSL8041 is not difficult to strap since it doesn't share any strap inputs with the MII bus and so there are no ports which will possibly conflict.

Communication takes place over the maintenance interface. In the M5223X project the routines fnMIIread() and fnMIIwrite() are used for this. In the M5225X project these are also used but, instead of being internally connected to the internal EPHY) they are connected externally with the external PHY. (FEC_MCD and FEC_MDIO). Note that these have external pull-ups on the M52259DEMO COM board and probably need these (the MDIO is bi-directional and normally open drain - it operates at 2.5MHz and so 3k3 pull up is a good choice).

Regards

Mark
Title: Re: ksz8041 PHY chip for 52259
Post by: neil on January 27, 2009, 11:25:26 AM
Hi Mark,
  I understand things better regarding the PHY,thanks for all your time explaining this, cheers.

I know the 52235 had problems with auto-negotiation , I assume this is not an issue with external PHY now?

Was the internal PHY a big cause for the 5223x chip for being so hot?

Thanks again
Neil
Title: Re: ksz8041 PHY chip for 52259
Post by: mark on January 27, 2009, 11:46:44 AM
Hi Neil

The external PHYs have no such problems with auto-negotiation.
Also the M52259 runs much cooler because the EPHY causes the M5223X it to get quite hot.

Regards

Mark
Title: Re: ksz8041 PHY chip for 52259
Post by: neil on January 30, 2009, 11:18:03 AM
Hi Mark,
   Thanks for all your help on this part, just a few more questions if thats ok?

1. I will copy the pull downs as in M52259DEMOCOM diagram (there are no external pullups), and connect reset pin to processor i/o pin, this fine?.

2. MDIO/MDC pins not in strap input, but pulled low on M52259DEMOCOM diagram. Is it best to copy this?

3. I notice on the M52259DEMOCOM diagram there are no external pullups on NWAYEN for auto negotiation, and SPEED for 100Mbps. Does the M52259 change this in software , depending on the value in NETWORK_PARAMETERS.usNetworkOptions during initialisation?

4. As the reset pin will be connected to an io pin, is it best to have a pull up resistor on this so it comes out of reset when power is applied?

5. Does the PHY get the MAC and ip address from the M52259? If so, then does the PHY only pass info to 52259 that has matching MAC and IP address?

6. If I have to reset the device, what part of the initialisation is this done? And if so is there anything to send to it through the  fnMIIwrite() commands to initialise it?

Thanks again Mark
Neil
Title: Re: ksz8041 PHY chip for 52259
Post by: mark on January 30, 2009, 12:17:02 PM
Hi Neil

1. Be careful RN2 is a pull-up so there are some pull-ups involved. Reset to I/O is not really necessary with the Micrel since there are no conflict possibilities, but it won't hurt to be able to control it.
2. Also here these are pull-ups and not pull-downs. Pull ups are necessary - at least on the data line.
3. The LEDs act as pull-ups. In any case, all default settings (apart from address) can be changed later via the management interface. Then the final setting is defined by parameters.
4. It doesn't really matter whether the PHY comes out of reset immediately or only then when programmed, but check the RESET timing to ensure that the reset is held long enough to be reliable.
5. The PHY does not MAC / IP filtering. All of this is done in the MAC. The PHY is converting pulses on the LAN to digital data and its function is essentially analog and has no digital intelligence (apart from negotiation and possible additional functions)
6. When the device is reset it reads the strap inputs and uses these settings. Changes to the strapped settings can then only be performed via the fnMIIWrite() commands. Normally a reset after initialisation is never required. It is also possible to command a soft reset via management interface.

Regards

Mark
Title: Re: ksz8041 PHY chip for 52259
Post by: neil on January 30, 2009, 12:31:14 PM
Hi mark,
  Thanks for help. I never noticed RN2 was a pull up 

I notice that on the M52259DEMOCOM, the reset pin is not connected to anything, and doesnt seem to have an internal pullup going by the data sheet. How is this dealt with on the M52259DEMOCOM board?

Neil
Title: Re: ksz8041 PHY chip for 52259
Post by: mark on January 30, 2009, 01:10:16 PM
Hi Neil

This line is driven from the MCU board which has a pull-up resistor 4k7 and also a RESET LED to 3V3. When the reset output of the Coldfire is active it drives this from U3. See page 3 of the DEMO MCU circuit diagram.

Regards

Mark
Title: Re: ksz8041 PHY chip for 52259
Post by: neil on January 30, 2009, 01:17:21 PM
Hi Mark,
  Thanks, I never saw that. I guess I can just do this instead using a io pin.

Neil
Title: Re: ksz8041 PHY chip for 52259
Post by: mark on January 30, 2009, 02:30:50 PM
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
Title: Re: ksz8041 PHY chip for 52259
Post by: neil on February 07, 2009, 10:43:48 AM
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
Title: Re: ksz8041 PHY chip for 52259
Post by: mark on February 07, 2009, 03:15:59 PM
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
Title: Re: ksz8041 PHY chip for 52259
Post by: neil on February 07, 2009, 05:01:56 PM
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
Title: Re: ksz8041 PHY chip for 52259
Post by: neil on February 10, 2009, 11:23:32 AM
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
Title: Re: ksz8041 PHY chip for 52259
Post by: mark on February 10, 2009, 05:29:46 PM
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
Title: Re: ksz8041 PHY chip for 52259
Post by: neil on February 10, 2009, 05:47:18 PM
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
Title: Re: ksz8041 PHY chip for 52259
Post by: mark on February 10, 2009, 07:56:50 PM
Hi Neil

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

Regards

Mark
Title: Re: ksz8041 PHY chip for 52259
Post by: neil on February 10, 2009, 08:16:46 PM
Hi Mark,
  As the reset would have to be done before utasker talks to the PHY, how is this best performed?

Regards
Neil
Title: Re: ksz8041 PHY chip for 52259
Post by: mark on February 10, 2009, 08:52:34 PM
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
Title: Re: ksz8041 PHY chip for 52259
Post by: neil on February 10, 2009, 10:00:02 PM
Hi Mark,
  Thanks., much appreciated

Neil
Title: Re: ksz8041 PHY chip for 52259
Post by: neil on February 13, 2009, 01:55:29 PM
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
Title: Re: ksz8041 PHY chip for 52259
Post by: mark on February 13, 2009, 06:12:55 PM
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
Title: Re: ksz8041 PHY chip for 52259
Post by: mark on February 14, 2009, 12:32:23 AM
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