cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Observer
Observer
6,459 Views
Registered: ‎08-11-2014

Xilinx SDK lwIP Echo Server Overflow

Jump to solution

Hello All,

 

You've helped out a great deal in the past, so I'm hoping for more of the same again. Currently I'm attempting to build and run the Xilinx provided lwIP Echo Server Demo, which is a specific option under the New Application Project. The program will run on the ML-505 dev board. I've attached some images that show the issue: it appears that no matter how far down I reduce lwIP options within the Board Support Package Settings, I can't get it to fit within the BRAM of the device. 

 

Has anyone else ever experience this issue? I have changed nothing from the provided source files.

part 1.PNG
part 2.PNG
part 3.PNG
0 Kudos
Reply
1 Solution

Accepted Solutions
Visitor
Visitor
10,224 Views
Registered: ‎08-31-2014

Michael,

   I suggest taking a different approach then.  Build your FPGA design with a simple program that gives you confidence your system is operational (like a hello world on the serial port), but make sure you have the DDR memory available to the design and the debugger enabled too.  Program the FPGA with the bit file.  Then, connect to the MicroBlaze debug port using the Xilinx Microprocessor Debugger (XMD, User Guide 111, Chapter 10).  Using the debugger, you can halt the processor, download your elf to the attached DDR memory, and then tell the MicroBlaze to begin execution from the DDR memory.  It isn't elegant, but it will get you further so you can test your existing program with lwIP.  Also, this may indicate your design may require a boot loader program that fetches your elf from an on board memory, dumps it to the DDR, and then jumps into the application in DDR to begin execution.  So, in the end, you may have to create a monolithic flash programming file with the FPGA bitstream and elf in on board flash, and the FPGA bitstream may have a boot loading executable that copies a portion of the on board flash to DDR and then jumps to the DDR execution location.

-Jordan

View solution in original post

4 Replies
Visitor
Visitor
6,429 Views
Registered: ‎08-31-2014

Michael,

   Have you tried changing your compiler options to turn off debugging and increase optimization?  See this for details.

-Jordan
0 Kudos
Reply
Scholar
Scholar
6,424 Views
Registered: ‎09-05-2011
You might also want to take a quick look at the AR below:
http://www.xilinx.com/support/answers/36807.html
0 Kudos
Reply
Observer
Observer
6,420 Views
Registered: ‎08-11-2014

Jordan,

 

I have tried turning off the debugger completely and also increasnig optimization to maximum. Neither help in reducing the .text size. I don't believe that reducing these will affect the lwIP library, which is causing such a large increase in size.

0 Kudos
Reply
Visitor
Visitor
10,225 Views
Registered: ‎08-31-2014

Michael,

   I suggest taking a different approach then.  Build your FPGA design with a simple program that gives you confidence your system is operational (like a hello world on the serial port), but make sure you have the DDR memory available to the design and the debugger enabled too.  Program the FPGA with the bit file.  Then, connect to the MicroBlaze debug port using the Xilinx Microprocessor Debugger (XMD, User Guide 111, Chapter 10).  Using the debugger, you can halt the processor, download your elf to the attached DDR memory, and then tell the MicroBlaze to begin execution from the DDR memory.  It isn't elegant, but it will get you further so you can test your existing program with lwIP.  Also, this may indicate your design may require a boot loader program that fetches your elf from an on board memory, dumps it to the DDR, and then jumps into the application in DDR to begin execution.  So, in the end, you may have to create a monolithic flash programming file with the FPGA bitstream and elf in on board flash, and the FPGA bitstream may have a boot loading executable that copies a portion of the on board flash to DDR and then jumps to the DDR execution location.

-Jordan

View solution in original post