cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
fhurley
Participant
Participant
11,875 Views
Registered: ‎10-21-2008

Problem with Hard Ethernet MAC and lwIP: hanging in XLlTemac_Reset

Jump to solution

Hi there,

 

I am having trouble with my lwIP based application in EDK 11.4. My application ran fine in 11.3 but it seems that the upgrade broke something. After upgrading, I built a new system with BSB and set everything up the same (although some driver versions have changed).

 

At this point, I've removed everything from the application that is different than the standard Socket API lwIP example (such as found in xapp1026). The execution is hanging after calling xemac_add. I then traced through every function that is called by xemac_add and narrowed it down to the function XLlTemac_Reset, particularly line 353 in <EDK>\sw\XilinxProcessorIPLib\lltemac_v2_00_a\src\xlltemac.c.

 

It looks like the driver is polling a register until it matches a "reset done" bit but it's never getting there. Unfortunately there is no timeout either, which didn't make it any easier to find this problem. 

 

Is anyone else having this problem using lwip130_v1_00_b and lltemac_v2_00_a? I'm going to do a bit more debugging, then I guess I'll start a webcase.

 

Thanks for your help,

Ford 

 

0 Kudos
1 Solution

Accepted Solutions
fhurley
Participant
Participant
14,697 Views
Registered: ‎10-21-2008
Sorry for not following up to this post sooner. I noticed that the address that was auto-generated for the TEMAC peripheral was something like 0xfff00000. This seemed odd to me so I unmapped the address for it and and clicked "Auto Generate Addresses" again. After doing that it generated an address of 0x83c80000, and the problem went away immediately. I'm not sure why this was a problem to begin with, but perhaps something is wrong with the way BSB generates the address for the TEMAC. 

View solution in original post

8 Replies
andrewgschmidt
Adventurer
Adventurer
11,731 Views
Registered: ‎01-28-2008
I have also run across this bug since migrating to 11.4.  I have verified it with a couple of different interfaces for the Virtex4 (MII, RGMII, SGMII).  Had anyone see a solution from Xilinx yet?
0 Kudos
aminfar1
Explorer
Explorer
11,721 Views
Registered: ‎01-09-2009

Ford,

 

I am using XPS 11.4 and TEMAC 2.03. So far, I have used GMII and SGMII and my test peripheral application hangs, but lwIP has worked well. If you tell me in what situation that problem occurs, I can give it a try and let you know the results.

 

Thanks,

aminfar

0 Kudos
fhurley
Participant
Participant
14,698 Views
Registered: ‎10-21-2008
Sorry for not following up to this post sooner. I noticed that the address that was auto-generated for the TEMAC peripheral was something like 0xfff00000. This seemed odd to me so I unmapped the address for it and and clicked "Auto Generate Addresses" again. After doing that it generated an address of 0x83c80000, and the problem went away immediately. I'm not sure why this was a problem to begin with, but perhaps something is wrong with the way BSB generates the address for the TEMAC. 

View solution in original post

andrewgschmidt
Adventurer
Adventurer
11,688 Views
Registered: ‎01-28-2008

I did notice the address generated was a little strange.  I just tried changing the address to the address you gave (I also tried generating) and am still stuck in the same place.  Were you using the XAPP1026 source code or did you directly use the RAW Echo test provided by the SDK?

 

0 Kudos
fhurley
Participant
Participant
11,686 Views
Registered: ‎10-21-2008
My code was the same as the xapp1026 SOCKET echo test. I haven't tried RAW.
0 Kudos
vneethv
Participant
Participant
11,135 Views
Registered: ‎05-31-2010

Hi,

 

I have got the similar problem. I've generated a new hardware with LL0_TEMAC and DDR2. i am trying out an LwIP based TCP server (using SOCKET_API). It seems like the application always hangs @ xemac_add call. When i checked using the debugger i found that it is always hanging at XLlTemac_PhyRead() function.

Please find the below code:

 

/* Wait here polling, until the value is ready to be read.*/
do {
Rdy = XLlTemac_ReadReg(InstancePtr->Config.BaseAddress,
XTE_RDY_OFFSET);
} while (!(Rdy & XTE_RSE_MIIM_RR_MASK));

 

My application always hangs at this particular point. Is there any settings that i am missing ?

0 Kudos
fhurley
Participant
Participant
11,013 Views
Registered: ‎10-21-2008

Try unmapping the generated address range and generating a new address for the LLTEMAC peripheral. To do this, go to the "addresses" tab in XPS and changing the size setting for the TEMAC to U. Then click Generate Addresses in the top right corner. 

That worked for me.

0 Kudos
alexsvet
Adventurer
Adventurer
10,319 Views
Registered: ‎08-05-2008

Altough the topic is marked as solved, we are not there yet completely.

 

Unmapping the generated address range and generating a new address for the LLTEMAC peripheral does solve problem on some occasions. But on some other it doesn't...

 

I have two designs for ML410. One works and the other doesn't. The one that doesn't hangs

at function XLlTemac_Reset(), where it waits for MGT to lock (SGMII TEMAC). BTW, I have

configured the board so that it uses ML410 onboard SGMII clock.

 

 

The first design basically consist of PPC405, DDR2 and SGMII TEMAC connected to SDMA

port of MPMC for DDR2 and INTC. There are some other minor peripherals included in this design.

(I have attached MHS files for both designs.)

 

The second (nonworking) design has additional MPMC for DDR and SYSACE controller.

My guess is that the additional MPMC is causing the troubles. But I still have to confirm this

with putting together two designs with minimal differences.

 

 

 

TEMACs in both designs are located at address 0x83C80000.

I dumped the memory at location TEMAC base address at entering XLlTemac_Reset().

 

The working design returns nonzero data at offset 0x0C and 0x2C.

Base address + 0x0C : 0x0C               (interrupt status for TEMAC0)

Base address + 0x2C : 0x0001007F (ready status for TEMAC0)

 

Interrupt status indicates that the MGT clock has been locked. 

Additionally, RxDcmLock bit has value '1' which is hard-coded for hard TEMAC.

 

 

On the other hand, dumping memory at address 0x83C80000 for nonworking design

returns all zeros for offsets from 0x0 to including 0x3C. Which is strange.

At least RxDcmLock bit should have value '1'.

 

It looks like the TEMAC is not present on the bus on the second design.

Or at least it is located somewhere else. Which might be connected to

the first problem with generated 'strange' default address for TEMAC (0xFFF00000).

 

Does somebody have any clue where to continue searching for the problem?

 

Thanks,

~Aleš