Lpc1768 + lan8720

cancel
Showing results for 
Search instead for 
Did you mean: 

Lpc1768 + lan8720

897 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by trueloop on Mon Jul 05 03:04:09 MST 2010
Hello,
I try to implement the uIP port on my own hardware with an LPC1768 and PHY "LAN8720". The software is running on a evaluation board with LPC1768 without problems. But if I debug the software on my own hardware the debugger (LPCXpresso) hangs after reset all datapath and host registers. I think this behaviour had nothing to do with the hardware at this moment.

  /* Power Up the EMAC controller. */
  LPC_SC->PCONP |= 0x40000000;

  /* Enable P1 Ethernet Pins. */
  LPC_PINCON->PINSEL2 = 0x50150105;
  LPC_PINCON->PINSEL3 = (LPC_PINCON->PINSEL3 & ~0x0000000F) | 0x00000005;

  /* Reset all EMAC internal modules. */
  LPC_EMAC->MAC1 = MAC1_RES_TX | MAC1_RES_MCS_TX | MAC1_RES_RX | MAC1_RES_MCS_RX |
             MAC1_SIM_RES | MAC1_SOFT_RES;

---> after this command the debugger hangs
  LPC_EMAC->Command = CR_REG_RES | CR_TX_RES | CR_RX_RES | CR_PASS_RUNT_FRM;

  /* A short delay after reset. */
  for (tout = 100; tout; tout--);


Does anyone already met this problem?
0 Kudos
8 Replies

188 Views
seneryetgin
Contributor I

Hi,

I've come across here while I was trying to find a solution for the very same issue of myself. For my instance, it was also hardware issue.
Although all the schematic and design were looking identical to my eval board, my custom board was failing after each JTAG debug attempt and the debug stops. But, the application was uploading alright. Only the debug was problematic. Until I cycle the power it was staying stuck.

Finally I found the issue. It was about two function pins on the LAN8720.

According to the document "LAN8720A QFN Rev D Schematic Checklist.pdf";

The polarity of LEDs on those pins must be correct: LED2/nINTSEL and LED1/REGOFF

The LED functionality signal pins are shared with the REGOFF & nINTSEL functionality
of the LAN8720. The pinouts are as follows:

LED1 is shared with REGOFF on pin 3.
LED2 is shared with nINTSEL on pin 2.

My LED polarities were opposite to what they have to be. Once I corrected them, things started to act normal.

Regards,
Sener

0 Kudos

306 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ashgupta28 on Tue Dec 09 01:47:07 MST 2014
Hello pres2300,

I am also using custom board with LPC18xx with KSZ8863RLL. I am trying to read & write PHY registers. Actually I am using CLOCK MODE & MDIO SMII Mode (RMII mode) to access registers. I guess as per the MII format, only 5bit register address & 5 bit Phy address can be used.
I am using 25MHZ crystal populated at X1 & X2 at PHY switch.

BUT I AM GETTING GARBAGE VALUES WHILE READING THESE KSZ8863RLL REGISTERS

HERE ARE THE STEPS I AM FOLLOWING:-
1.Configure the LPC processor clock & enabled the RMII interface of LPC
2.Configure the PHY address PHY 1( this configuration helps to create the RMII frame format and adding the PHY address 0x01 in PHY address Bits[4:0]
3.As per our set up, LPC processor is receiving 50MHz reference clock.(Please correct me if I am wrong). So what settings need to be in done in LPC as per clock. I have selected CLK_M3_ETHERNET/102

4.After that I tried to read MII_PHYSID1(0x02) & MII_PHYSID2(0x03) with PHY address 0x01. It will return only 16bit data (should return 0x0022 & 0x1430) as per the format. But I receive only the garbage value. Also I tried to connect the LAN cable at port 1 & tried to read the MII_BMSR to check the LINK up or down but the value I am reading is 0x0000 every time. The LEDs & LINK LEDs blinks properly after connecting the cable but still I am getting 0x00 value.

if (lpc_mii_read(0x00, &tmp) != SUCCESS) {
return ERROR;
}

I have selected PHY address 1 & trying to read 0x00 register
lpc_read_read is actually configuring the packet as per the datasheet & sending to Micrel chip

Thanks
0 Kudos

306 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by pres2300 on Tue Mar 05 17:09:49 MST 2013
I hate to rise a forum post from the dead, but I ran into this issue and found this forum while searching for solutions.  In case anyone else that has similar issues finds this forum like I did, I would like to post my solution.

I am using a custom PCB with a Micrel KSZ8863RLL switch chip.  We are using the switch chip with only strap option configuration so no direct register writes through the MIIM interface are being used.  I was having the same issue with the JTAG debugger losing communication directly after resetting the MAC interface on the LPC1768.  If you read in page 181 of UM10360 (the user's manual for the LPC1768), it states that the ENET_REF_CLK signal MUST be present before configuration of the MAC takes place.  Otherwise, the CPU becomes locked and JTAG communications are lost.  Our problem was with a design error in our PCB where we didn't have the RMII reference clock output of the switch chip wired to the ENET_REF_CLK input of the LPC1768.  I hope this helps anyone that stumbles on this forum as I did.
0 Kudos

306 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bbtao on Wed May 25 05:41:39 MST 2011
I have the same problem too,I still donot succecc debug  the esyweb.c on lpc1768+lan8720,I want to konow that does anyone who have succecced ?Can you send you software to me ,thanks!
Email:1059062966@qq.com.
0 Kudos

306 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by trueloop on Wed Mar 02 06:52:49 MST 2011
The pull up on pin 12 (MDIO) was lacking. Take a look to https://www2.smsc.com/...lancheck.../Schematic%20Checklist%20LAN8720%20QFN%20Rev%20B.pdf .
0 Kudos

306 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by SolomonViveros on Mon Feb 28 15:24:45 MST 2011
I too am curious as to what the hardware problem turned out being? I'm experiencing a similar problem and have yet to find the source of the problem.
0 Kudos

306 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by kiryat8 on Mon Feb 21 07:47:08 MST 2011
We have two  boards that exhibit the same behavior you describe and two boards that work fine. What was your hardware problem?
0 Kudos

306 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by trueloop on Mon Jul 05 05:05:45 MST 2010
Problem solved! It was a hardware problem!
0 Kudos