UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor pguillem
Visitor
875 Views
Registered: ‎02-11-2011

Trouble Running Project In SDK

Jump to solution

Hi,

 

I'll start with the connectivity.

Workstation1 --LAN--> Worstation2(hw_server) --USB2JTAB-->Board( JTAG pins --> ZYNQ --> VIRTEX7( Microblaze ) )

 

When I inherited the project, I was able to make changes to the microblaze code, compile it, then run it where I would see the print statements in the console/terminal.

 

At this moment, if I load the bit file, I can then see the print statements, but if I make changes to the code, I have to compile it, build a new bit file then load the bit file to see the results.

 

Here is the Run Configuration page.

RunConfiguration.png

 

As you may surmise, I am not an experienced FPGA designer and so I could really use some hand holding to fix this problem.

 

Any help would be very much appreciated.

 

BR,

Phil

0 Kudos
1 Solution

Accepted Solutions
Visitor pguillem
Visitor
927 Views
Registered: ‎02-11-2011

Re: Trouble Running Project In SDK

Jump to solution

Solved it, though not really sure what happened to cause the problem.

 

I happened to look at the .elf file "Run Configuration" and saw that it was not the same as the saved configurations.  I set it as below and now it works again.

 

Thanks for the help.

 

BR,

Phil

Run_Configuration.pngRunConfiguration.png

0 Kudos
7 Replies
Moderator
Moderator
836 Views
Registered: ‎09-12-2007

Re: Trouble Running Project In SDK

Jump to solution
Yes, this is not ideal. It sounds like you are placing the updated elf into bram then building the bit (implementing in vivado) and downloading this??. This would be time consuming and frustrating.

You can update the elf via the debugger on the existing bitstream. You would need to place a mb-bootloop elf in the bram though, to keep the microblaze ticking over (basically the mb will start to fetch/execute intstr once it comes out of reset. the boot loop stops it getting illegal instr; 0x0) until you pass in your application elf. You should be able to pass in your application elf in the application tab in the run config GUI you posted.

Or, if you are placing your application in bram. You could use the updatemem to populate the bram with your elf. You would need an Mmi file. The mmi file is created for all memory mapped memory controllers on the microblaze in the block design (bd). So if you are using this flow, then the mmi should be in the impl folder in vivado project. If you are not using the bd to create the hw, then you would need to manually create the mmi. (See chapter 7 below)

The command line would look like:
updatemem -meminfo test.mmi -data test.elf -bit s2_v7_fpga_top.bit -proc microblaze_o -out download.bit

Note: the -proc info would be the instpath string in your mmi file. Each memory range would have an instpath.

You can then replace your s2_v7_fpga_top.bit with the output download.bit in SDK. Then everytime you change your app elf, just re-run updatemem.

Updatemem sounds like the best flow, as you don’t seem to be debugging the code on the mb? If you want to debug then download the bitstream (using xilinx-program fpga), then create a debug configuration and target your microblaze.

Reference: updatemem in chapter 7
https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_1/ug898-vivado-embedded-design.pdf
0 Kudos
Visitor pguillem
Visitor
823 Views
Registered: ‎02-11-2011

Re: Trouble Running Project In SDK

Jump to solution

In order to meet timing, one thing that I have been doing is trying to remove blocks that are not needed, some were there for initial familiarization with Vivado and IPI.

 

I removed the AXI EMC since all its ports that left IPI were unconnected in the verilog code.  Based on your comments, this is probably the memory controller that allowed proper communication.  That explains the don't touch attributes.

 

I'm going to try putting it back in to see whether this helps.

 

Thank you,

Phil

0 Kudos
Moderator
Moderator
769 Views
Registered: ‎10-06-2016

Re: Trouble Running Project In SDK

Jump to solution
Hi @pguillem,

Did you made any progress on this? Would be nice if you could share it with the community :)

Regards
Ibai

Ibai
Don’t forget to reply, kudo, and accept as solution.
0 Kudos
Visitor pguillem
Visitor
751 Views
Registered: ‎02-11-2011

Re: Trouble Running Project In SDK

Jump to solution

Not yet.  I took an old project and added my .v and .c modifications in the hopes that it might work.  No luck.

 

I had to deliver something else, but I am hoping to soon read through the material pointed to in the hopes of figuring out what went wrong.

 

Does this usually work when connecting to a board via hw_server on another machine?

 

BR,

Phil

0 Kudos
Moderator
Moderator
745 Views
Registered: ‎09-12-2007

Re: Trouble Running Project In SDK

Jump to solution

Ok, can you send a block diagram of your system. Where are you placing your application? in What memory? 

Is this memory external to the FPGA? ie not in BRAM? if so, then my previous suggestion is not valid.

0 Kudos
Visitor pguillem
Visitor
741 Views
Registered: ‎02-11-2011

Re: Trouble Running Project In SDK

Jump to solution

The quick answer is that it is in the FPGA Memory.  The board has 2 FPGAs and the one of interest has no external memories.

 

To be honest, I have no clue as to where the application is being placed.  I am guessing that it is in the microblaz_0_local_memory seen in the image below.

 

uB_application_memory.png

As I mentioned, I inherited this project and am learning as I go.  How do I confirm the application storage location?

 

Thanks,

Phil

0 Kudos
Visitor pguillem
Visitor
928 Views
Registered: ‎02-11-2011

Re: Trouble Running Project In SDK

Jump to solution

Solved it, though not really sure what happened to cause the problem.

 

I happened to look at the .elf file "Run Configuration" and saw that it was not the same as the saved configurations.  I set it as below and now it works again.

 

Thanks for the help.

 

BR,

Phil

Run_Configuration.pngRunConfiguration.png

0 Kudos