UART does not work on Nexys 4 DDR when following tutorial

[dmishins]

Hi,

I am trying to follow the Nexys 4 DDR getting started with microblaze tutorial         and I'm having trouble completing step 20.  I believe I followed step 11 correctly, but when I get to step 20, if I set the memory region to mig_7series_0_memaddr  (I have no option for just mig_7series_0, as specified in the tutorial), nothing transfers over UART when I run the program on the FPGA.  If, however, I leave the default memory region (microblaze_0_local_memory_ilmb_bram_if_cntlr_Mem_microblaze_0_local_memory_dlmb_bram_if_cntlr_Mem), UART seems to work fine and I get "Hello World" printed.

Can someone help me understand the meaning of this setting, and will leaving it set to microblaze_0_local_memory... cause any problem in this project/future development?  Ideally, I would like to build up to projects that use the capability of the DDR2 memory.

Thanks,

Daniel

[jpeyron]

Hi @dmishins,

Sorry about the additional QSPI functionality in the project. You do not need the QSPI Flash IP Core unless you are planning on configuring the Flash with your project.  

Here is a completed and verified Nexys 4DDR uart with changing the linker script to the DDR in SDK.

I believe the error you are getting is from not exporting the hardware including the bitstream. It might be easier to start with a fresh project.

best regards,

Jon

[jpeyron]

Hi @dmishins,

Welcome to the Digilent Forums!

Please attach a screen shot of your Block design.

Did you connect the 200 MHz clock to the MIG as instructed in section 10?

What did you set the local memory and cache when running clock automation for Microblaze?

best regards,

Jon

[dmishins]

Hi Jon,

Thanks for the reply and the welcome!

I was a bit confused by step 10 because the 100 MHz system clock was already connected (I think from running connection automation in the step before), so I disconnected it by deleting the entire line for the system clock, manually connecting it to the 200MHz clock, and then re-running connection automation to fix all the other components that used the 100MHz sys_clock.

I believe I was careful to copy the settings from the image in the tutorial, but I'm not 100% sure and I don't know how to check those settings now.  If I remember correctly, I set local memory to 32K and Cache to 16K.

I've attached the block design.  Out of curiosity, is there any special feature to block designs that can't be done using the ip catalogue?  Is everything in a block design eventually combined down to sources in the same way that they could be added manually? I'm having trouble understanding when to use the block design, and when to directly add sources (especially when trying to mix microblaze/IP with my own vhdl).

Thanks again,

Daniel

 

 

 

EDIT: One thing I noticed after posting this is that in the "Board" folder it suggests that the DDR2 is not connected, despite it showing the connection on the right side of the diagram.  The ddr2 also seems to be connected when I look at the synthesis IO planning window.  Could that be related?

[jpeyron]

Hi @dmishins,

Here is a verified and completed Nexys 4DDR Vivado 2018.2 qspi flash project.

My boards tab does show that the qspi is connected so that might be the issue.

I used 50 MHz from the clocking wizard for the ext_spi_clk on the qspi flash ip core and 200 MHz for the sys_clk_i on the Mig-7.

I have attached screen shots of the process.       

best regards,

Jon

[dmishins]

Hi Jon,

Thanks again for your help.

Is it necessary to include the QSPI in this program?  I was planning on loading the program from my computer over usb when running it, and have no need for persistent memory, just ram.

I tried adding the DDR2 connection from the board port to my design, and reverified the design, then regenerated the outputs, rewrote the bitstream, and now when I try to export the hardware to the SDK to test I get the following common error:

Quote

The hardware handoff file (.sysdef) does not exist. It may not have been generated due to: 1. A bitstream might not have been generated. Generate Bitstream and export again, or do not request a bitstream to be included in export. 2. There are no block design hardware handoff files. Check the vivado log messages for more details.

I've tried all the suggestions to solve it I've found on the Xilinx forums.  Any ideas to go forward?

Thanks,

Daniel

 

EDIT: Generating the IP for microblaze as "Out of context per IP" as opposed to "Global" seemed to fix the problem.  I'm not sure what that did though. I still have the issue where no data is sent through UART if the linker settings are set to mig.

 

[dmishins]

Hi Jon,

Thank you so much! Your project seems to work fine on my computer, even after I regenerated the IP to update them and regenerated the bitstream.  I'm trying to figure out what the difference could be between the projects, and ideally figure out what is wrong without just starting over.  The only difference  I can see in our block designs is that yours has an axi_smc block to connect to MIG whereas mine connects through the microblaze_axi.  Could that be the difference, and is there a way to fix that?

 

EDIT: That was the difference.  I redid the tutorial from a new project making sure to follow everything exactly, and It now generates the same design that you got.  Any idea what I did wrong before?  Also, another thing that changing this brought up, is now pushing the cpu-reset button doesn't seem to reset the CPU.  Any idea on why that would change and how to fix that?

Thanks,

Daniel

[jpeyron]

Hi @dmishins,

On page 30 of the reference manual here states:

" The red pushbutton labeled “CPU RESET,” on the other hand, generates a high output when at rest and a low output when pressed. The CPU RESET button is
intended to be used in EDK designs to reset the processor, but you can also use it as a general purpose
pushbutton. Slide switches generate constant high or low inputs depending on their position."

So in this case if resets the Microblaze processor. I do not believe pressing the cpu-reset would re-run the application though. If you are wanting to configure the FPGA (including the SDK Application) on power up then you would want to use the QPSI Flash or SD card.

best regards,

Jon

[dmishins]

Hi Jon,

That makes sense, I guess I shouldn't expect consistent results out of undocumented behaviour.

Thanks again for all your help.  I think that solves my problem, though in the process of solving this one, another problem came up.  I guess thats a topic for another thread...

Thanks,

Daniel