01-14-2010 11:43 AM
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,
03-01-2010 11:09 AM
02-26-2010 09:10 AM
02-26-2010 02:35 PM
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.
03-01-2010 11:09 AM
03-01-2010 12:08 PM
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?
06-01-2010 10:07 PM
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.*/
Rdy = XLlTemac_ReadReg(InstancePtr->Config.BaseAddress,
} while (!(Rdy & XTE_RSE_MIIM_RR_MASK));
My application always hangs at this particular point. Is there any settings that i am missing ?
06-07-2010 09:19 AM
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.
09-21-2010 12:20 AM - edited 09-21-2010 12:22 AM
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?