Olimex LPC2378-STK ethernet problem

[mark]

Martin

Great - Rowley is certainly a great solution for using GCC without the investment needed to get everthing working. It has probably the widest debugger support available and also included optimised libraries and very good support!

Regards

Mark

[olimex_man]

Hi Mark.
I found something. I run the debugger and the simulator and compare every statement and the written values in fnConfigEthernet() ....no differences.
BUT

Code: [Select]

    ulPhyIdentifier = fnReadMII(DP83848_PHY_IDENTIFIER_1);               // check that the PHY is working correctly by reading its identifier
    ulPhyIdentifier <<= 16;
    ulPhyIdentifier |= fnReadMII(DP83848_PHY_IDENTIFIER_2);              // check that the PHY is working correctly by reading its identifier

    if ((ulPhyIdentifier & PHY_MASK) != PHY_IDENTIFIER) {
        return;                                                          // if the identifier is incorrect the phy isn't resonding correctly
    }
at this point the target failed the if-instruction and returns. So, as you thought, its a problem with the PHY.

[mark]

Martin

If you ignore the PHY check it may then run correctly. However, can you say what value is being read from the PHY?

Regards

Mark

[olimex_man]

I removed the PHYcheck and it works now. Great. Thank you for the help.

But one more thing is strange:
It is not working every time. Sometimes it return in the following statement:

Code: [Select]

    while (fnReadMII(DP83848_BASIC_CONTROL_REGISTER) & PHY_SOFTWARE_RESET) {// wait until reset completed
        if (--i == 0) {                                                  // quit if no response
            return;
        }
    }
So it is necessary to restart a few times.

However, can you say what value is being read from the PHY?

The expected value is 0x20005C90. Is that right? The debugger shows that the value that is being read is 0x00221610.


Regards
Martin

[mark]

Martin

The Olimex board uses a Micreal KSZ8721BL as PHY. I think that your project may be set up to use the DP83848 as is on the KEIL board - check that you are using the define OLIMEX_LPC2378_STK, and not KEIL_MCB2300 (in config.h). Check also that you have at least service pack 1 installed since the Olimex board was not supported in the orginal release.

You say that you are reading 0x00221610 - the Micrel part has the ID 0x00221619 (are you sure about the 0 at the end?)

The number is read from two registers and has the following meaning:
- 0x002214 is the OUI (Organisationally Unique Identifier) belonging to Micrel b0000000000100010000101
- 0x21 (overlaps with the end of the OUI) b100001 and is the manufacturer's model number - ie the KLZ8721BL
(the above is then 0x0022161x)
- then follows a 4 bit revision number b1001 = 0x9 according to the latest data sheet, giving the ID which is checked for.
If you are really reading a 0x0 at the end it means that the chip must be rather old!!

There is however something which needs to be improved. If you look in the check it is like this:
(ulPhyIdentifier & PHY_MASK) != PHY_IDENTIFIER
The idea of the PHY_MASK is to mask out the revision number when comparing, but the Olimex project uses this set to 0xffffffff, so it will not accept PHYs with changed revisions. The reason for this is probably the Micrel data sheet where the text to the revision numer if misleading:
Revision number : 4 bit manufacturer's model number.

This is not a model number and so could change!!

If your code is really checking against 0x20005C90 it is expecting the NATIONAL DP83848 identifier (from Keil board). Otherwise they are however more or less equivalent.

If the reset command is sometimes failing you could try increasing the wait time allowed:
i = 1000000; -> i = 10000000; to see whether it is a timing issue or not.
If it still sometimes fails it is probably some communication unreliability rather that the wait limit being critical.

Good luck

Regards

Mark

[olimex_man]

Hi.

You say that you are reading 0x00221610 - the Micrel part has the ID 0x00221619 (are you sure about the 0 at the end?)

You are right, it is a 9. Don´t know where i saw the 0.

But the other thing is strange. As you see

Code: [Select]

/#define _LPC21XX                                                     // specify LPC21XX subset
    #ifdef _LPC21XX
        #define IAR_LPC210X
        #define TARGET_HW           "IAR LPC210X Card"
    #else
        #define OLIMEX_LPC2378_STK                                     
        #define TARGET_HW           "OLIMEX_LPC2378_STK"
    #endif
I changed the value in config.h. Nevertheless the checking value is 0x20005C90.
I´m using uTaskerV1.3_beta-LPC....thought this is the last release?

If the reset command is sometimes failing you could try increasing the wait time allowed:
i = 1000000; -> i = 10000000; to see whether it is a timing issue or not.
If it still sometimes fails it is probably some communication unreliability rather that the wait limit being critical.

I increased the wait time, but it still sometimes failed. So it is not a problem with the wait limit. Any idea about that?

Thanks
Martin


EDIT:
I downloaded the ServicePack 3 and I see my version is not the newest one. Sorry for that. Thought all the time my version is the newest one. My fault. So i gonna test it with the new files.

EDIT 2:
ok, it works. And the chekcing works now to. Of course it does, now it is expecting the right value.


But the problem with the reset command in

Code: [Select]

while (fnReadMII(DP83848_BASIC_CONTROL_REGISTER) & PHY_SOFTWARE_RESET) {// wait until reset completed
        if (--i == 0) {                                                  // quit if no response
            return;
        }
    }
is still there.


EDIT 3:
The problem only occurs while debug sessions or after a board reset (with the reset button). When I unlink the power supply and connect to the board, ist starts without any problems. Every time. But this other users in this forum topic reported too.

Regards
Martin

[mark]

Hi All

I would like to thank Fabrizio for some feedback that he sent me concerning his experience with the Olimex LPC2378-STK and the PHY addressing.

First of all he explained to me the way that he ensures that the PHY is always detected:

In extern void fnConfigEthernet(ETHTABLE *pars)


    #ifdef OLIMEX_LPC2378_STK   // MICREL PHY KSZ8721
    fnInit_KS8721PHYADDRESS();
    #endif

//_______________________________________________________________________
// See Micrel PHY KS8721 Users Manual on "Strapping Option"
// KS8721 Internal Pull-Up/Down can be overridden from attached Hardware.
//_______________________________________________________________________
void  fnInit_KS8721PHYADDRESS(void)
{
unsigned long ulPhyIdentifier;
unsigned long PhyAddr;

 for(PhyAddr=1; PhyAddr < 32; PhyAddr++)
  {
    ulPHY_ADDR = PhyAddr << 8;
    ulPhyIdentifier  = fnReadMII(DP83848_PHY_IDENTIFIER_1); 
    ulPhyIdentifier <<= 16;
    ulPhyIdentifier |= fnReadMII(DP83848_PHY_IDENTIFIER_2);
    if ((ulPhyIdentifier & PHY_MASK) == PHY_IDENTIFIER)
        return;                                                         
  }   
}

where
static unsigned long ulPHY_ADDR = PHY_ADDRESS_;
This variable is used in the PHY communication routines rather than a fixed address value.

He identified that the value found was not always constant but changed between 0x01, 0x09 and 0x19
This is due to the fact the LPC23XX ports have weak pull ups coming out of reset and the PHY has also internal weak pull ups/downs. The exact value is therefore not reliable since it floats around 1.5V.

The recommendation therefore (when hardware can be modified or can still be defined) is to use external pull ups / downs of around 4k7...10k to ensure the state out of reset and the address that the PHY actually assumes.

In the Atmel project the same effect is known and solved by commanding a subsequent reset of the PHY during configuration and actively driving the state temporarily: see http://www.utasker.com/forum/index.php?topic=161.0

Since the reset of the PHY is connected to the reset in line of the LPC23xx on the Olimex board this is not possible in this case. By controlling the PHY reset line from a port would allow this to be achieved though...possibly also via the RSTOUT...?

Regards

Mark

[mark]

Hi Martin

Are you sure that the IP settings in the demo match your network?

It is often helpful to do the same test using the simulator since this will allow you to verify this without having hardware involved which can sometimes have a difficulty causing the real problem.

It is to be noted that there are quite often some problems with particular cards and there are some workarounds that have been devised. For example see the following (toward the end of the thread there is something which can be tried - but it does involve rebuilding the project)
http://www.utasker.com/forum/index.php?topic=170.0

Regards

Mark