Author Topic: PHY configuration  (Read 27718 times)

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
PHY configuration
« on: January 23, 2008, 09:57:39 PM »
Hi All

After having a small difficulty with the demo project on an Olimex board it is interesting to discuss some details about the initialisation of the PHY chip to ensure that it initialises in the correct mode and has the correct address. This has resulted in a slight change in the project configuration code which you may like to take over from the details below.

At the time of writing the uTasker project for the SAM7X is delivered with configurations for two common evaluation boards: the ATMEL AT91SAM7X-EK and the Olimex SAM7-EX256.
The main difference between the Ethernet interface of the two boards is the use of different PHYSICAL layer devices: the AT91SAM7X-EK has a DAVICON DM9161A while the Olimex board uses the MICREL KS8721.

Fortunately the control of the PHYs are compatible (and standardised) to high degree. However the interface to these devices differs in some respects - mainly in the way that the PHYs are configured by port states on reset. It is typical to configure some PHY modes and the address of the device on the maintenance interface using pull-up and pull-downs at reset. Some of these configurations can be be reprogrammed later but a couple are critical so the Ethernet controller can even communicate with the PHY.

Examples of mode inputs are RMII mode, loopback or isolation mode.
The PHYs generally have a pull-up or pull-down to determine the stating mode if no external devices does it. This is also valid for the PHY address - for example the Micrel will default to address 0x01 since 4 address lines have pull-downs and ADD0 has a pull-up.

The configuration lines are also shared with other lines and so are generally connected also to the SAM7X. The SAM7X has pull-ups on its port lines by default and this can give a conflict with the PHY, which may have pull-downs. The question as to which wins the fight to determine the port state can not be determined so, if there is not also a stronger pull-up/down on the board to determine it, the defalt state is not really known.

The solution is to perform a second reset of the PHY while the SAM7X actively drives these configuration pins. This is performed in the Ethernet driver initialisation using the SAM7X feature of being able to generate a pulse on the reset output to reset external devices (without causing a CPU reset). Once the reset has completed, the SAM7X GPIOs can be programmed for MII use and the PHY is in the required mode.

It was found that the communication address of the PHY was not always as expected. The uTasker code uses 0x1f - ADD0..ADD4 = '11111' but the Olimex board, using Micrel PHY, was found to be defaulting to 0x01. This means that a check of the PHY ID (read on initialisation) was not causing a match and the Ethernet interface was subsequently not being initialised (this is interpreted as an error and the Ethernet initialisation is aborted).

A check of project code showed that the mode lines were correctly being derived on the second initialisation, but the PHY address lines were not. Since the code has been previously verified on Olimex boards it suggests that variations in the pull-up strengths between devices means that this may vary between boards and so a correction was necessary.

The following shows the improvement to ensure that the PHY address is controlled correctly.

In app_hw_sam7x.h the driving of the configuration lines are controlled using a define. The define varies between board type, and so there are 2 defines - one for the ATMEL and one for the OLIMEX board. The board type itself is selected in config.h.

ATMEL board code change

    #define PHY_ADD_31              (PB04 | PB05 | PB06 | PB13 | PB14)

    // DAVICON DM9161AE on ATMEL eval board
    // remove pullup on TEST input (MII ERXDV) so that device goes to normal mode
    // remove pullup on RMII input (MII ECOL) so that device uses MII mode
    // drive power down mode to '0'
    // drive PHY address to 0x1f (31)
    #define DRIVE_PHY_OPTION_LINES() PIO_PUDR_B = (PB15 | PB16); PIO_PER_B = (PB18 | PHY_ADD_31); PIO_OER_B = (PB18 | PHY_ADD_31); PIO_CODR_B = PB18; \
                                     PIO_SODR_B = (PHY_ADD_31);

The 5 connections from PB04, PB05, PB06, PB13 and PB14 drive the DAVICON pins (CRS, RXD0, RXD1, RXD2, RXD3) to '1' during the commanded reset. These lines latch in the PHY address on reset. Afterwards all pins are switched to their MII function.

OLIMEX board change

    #define PHY_ADD_31              (PB05 | PB06 | PB13 | PB14)          

    // set the option lines as we would like them to be for the MICREL PHY
    // drive to zero (default after reset)
    // drive PHY address configuration lines to correct address value
    #define DRIVE_PHY_OPTION_LINES() PIO_PER_B = (PCS_LPBK | ISOLATION_MODE | RMII_MODE | RMII_BACKTOBACK_MODE | PHY_ADD_31); \
PIO_OER_B = (PCS_LPBK | ISOLATION_MODE | RMII_MODE | RMII_BACKTOBACK_MODE | PHY_ADD_31); \
PIO_SODR_B = (PHY_ADD_31);

The 4 connections from PB05, PB06, PB13 and PB15 drive the MICREL pins (RXD0, RXD1, RXD2, RXD3) to '1' during the commanded reset. These lines latch in the PHY address on reset. Afterwards all pins are switched to their MII function.
The 5th address line (ADD0) is connected to the IRQ line of the PHY and defaults both at the SAM7X and MICREL to pull-up. Therefore this line doesn't need to be specifically driven. Afterwards it remains as input to detect interrupts originating from the PHY.

The modification for the Olimex board solved the problem. No known problems exist with the ATMEL board, but the change was successfully tested and should ensure that no problems are encountered in the future.

Regards

Mark



Offline zash

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: PHY configuration
« Reply #1 on: February 12, 2008, 09:24:09 AM »
Hi Mark and all uTasker users,

I am trying to work with AT91SAM7X256 and the PHY interface Teridian 78Q2123.

I have changed the following in app_hw_sam7x.h :

#define PHY_IDENTIFIER          0x0181b8a0
#define PHY_MASK                0xfffffff0
#define PHY_ADDRESS_ (0x1f << 23)

to

#define PHY_IDENTIFIER          0x000E7237
#define PHY_MASK                0xffffffff
#define PHY_ADDRESS_ (0x1<< 23)

but it still doesn't work.

If someone have experience with this PHY, help please.
I can provide the Teridian's pdf and my scheme, if needed.

Regards, Alexander

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: PHY configuration
« Reply #2 on: February 12, 2008, 11:50:40 AM »
Hi Alexander

Can you debug with your board?
If you can, and assumin the PHY is basically operating, you should be able to read its ID and then compare it to the one expected.
If the PHY is not responding you will generally read 0xffffffff (check also that any pull-up resistors required for the MDI interface are present). If it doesn't respond, try all possible PHY addresses (0x01..0x31) and it should respond on one of them. (To do this a break point can be set where it makes the read and the address 'manipulated' - best in assember mode and direct in the register holding the value to be written. If it doesn't respond, set the PC back to the previous location an dtry a different address, etc...).
If you can find the correct address you can then set it up in the define #define PHY_ADDRESS_ (0x1<< 23), although it may be necessary to understand the way that the address (and possibly modes) are configured on reset - see previous description.

It may also be that the mask used when checking the ID is not correct - the ID often contains a revision number, which can change. This should be masked out.

Good luck

Regards

Mark

Offline zash

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: PHY configuration
« Reply #3 on: February 14, 2008, 05:02:31 PM »
Hi,

There is a strange effect.
1. When I compile and debug with CrossStudio, there are non-stop interrupts and the value of AIC_IPR (0xFFFFF10C) is 0x80010000. Even the breakpoint in watchdog.c cannot stop the process.
2. When I compile and debug with IAR, the breakpoint in watchdog.c stops the process every time.

I cannot understand why there is such a difference between the two compilers.
Help me, please, if possible.

Alexander

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: PHY configuration
« Reply #4 on: February 15, 2008, 11:31:37 AM »
Hi Alexandra

The register shows that IRQ1 and EMAC interrupts are pending. I am assuming that the EMAC is causing the problem.
It is possible that the version of GNU which you are using (Crossworks is using) is optimising a register access away and causing an interrupt routine to be resulting in an endless loop when an Ethernet frame arrives.

Try changing the following define in sam7x.h:
#define EMAC_ISR    *(volatile unsigned long*)(EMAC_PERIPHERAL_BLOCK + 0x24)   // Interrupt Status Register

See also http://www.utasker.com/forum/index.php?topic=172.0

Such problems can be compiler dependent and occur when optimisation levels are changed or when new versions of compiler appear.

Good luck

Regards

Mark


Offline pzuidema

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: PHY configuration
« Reply #5 on: February 16, 2008, 12:12:27 AM »
Zash,

Try to mask out the revision part of the PHY identifier like Mark says:

#define PHY_IDENTIFIER   0x000E7230

In the SAM7_EMAC.c code I have the low 16-bit PHY ID is masked with 0xFFF0 and compared to the full PHY_IDENTIFIER.

I use the Teridian 78Q2133 and have no problem. Does your PHY crystal oscillate (25MHz) and do you have the Reset line (RSTN) pulled-up to 3.3V? Then the management port (max 25MHz) should work (MDC/MDIO). PHY_ADDRESS 1 is correct, but it also reacts on address 0 (broadcast).
I have an AT91SAM7X256 with FreeRTOS v4.7.0 and uIP 1.0.

Regards,
Peter