NEXYS 4 Programming Flash

[bhall]

Hello,

I am attempting to store a SDK program in SPI flash on a NEXYS 4. It is being powered via USB. My block diagram and C program are almost the same as in "Getting Started with the Vivado IP Integrator". I am using MicroBlaze.

I followed the tutorial "How To Store Your SDK Project in SPI Flash". The problem I am having is that unlike the tutorial, the nexys 4 does not have DDR, so on step 2.3 my only option for "Place Code Sections in:" is the MicroBlaze memory (see attached image). For "Place Data Sections in:" and "Place Heap and Stack in:" I can select the axi_emc memory that I assume communicates with the Cellular RAM on the board. I believe this is the problem but I'm not 100% sure. I can edit the lscript.ld to have all of the memory regions under axi_emc (see other attached image), but my program does not seem to be running after completing the remaining steps. 

I know that the issue is not not my block design or C program because I was able to successfully store and run it from flash using this tutorial. https://www.instructables.com/id/Flashing-a-MicroBlaze-Program/

The only problem with using the second method is that it runs the program in the FPGA's BRAM (I think). This might be an issue for me in the future if my program can not fit in the BRAM. 

Can anyone suggest a solution to my problem? Like I said, the other steps in the "How To Store Your SDK Project in SPI Flash" tutorial seem like they are finishing correctly but after programming and reboot, the "DONE" light turns on, but button presses do nothing to the lights and nothing appears in the terminal.

Thanks for your time and assistance in advance. Let me know if anything needs clarification. 

Brad 

[jpeyron]

Hi @bhall,

Welcome to the forums! The only choice is see is using the bram.  I believe you can make the bram larger using the linker script if needed but you are correct that there is a limit to the size.  You can compress the bitstream which should make the project size smaller.  Are you power cycling the Nexys 4 after configuring the flash? Are you changing the mode jumper JP1 to qspi? Have you confirmed that the project works when configuring the Nexys 4 normally?

thank you,

Jon

[bhall]

Hi Jon, 

Thanks for your reply. I'll try compressing the bitstream. I did power cycle the board after configuring, and jp1 is in the qspi position. The project functions correctly when I simply configure the FPGA with the program .elf.

Not sure why it won't let me use the external RAM, but I'll try to implement my project using BRAM. I'll update if I figure it out. I might try posting on Xilinx forums. 

Thanks again. Happy Holidays!
Brad

[jpeyron]

Hi @bhall,

Here is a mostly complete Nexys 4 QSPI flash project using Vivado 2018.2. You will need to finish the How To Store Your SDK Project in SPI Flash from step 3. Generate Bitstream with BRAM initialized with bootloader. I have attached the linker script that you should select(the cell ram).  

thank you,

Jon

[bhall]

Hi Jon,

Thanks for sending me this. I spent most of the day trying to get this to work and this is what I have figured out...

First, my problem was that my MicroBlaze did not have boxes checked for "Use Instruction and Data Caches" and "Use Cache for All Memory Accesses". I think this is what was preventing me from being able to place code sections into the external memory. I was able to select the axi_emc option after changing these settings.

After this was resolved my next problem was that the srec spi bootloader would not finish and load the srec that I was storing in flash. This occured in my project and the one you provided as well. The bootloader program was getting stuck at the XIsf_Initialize() function. It turns out that our AXI Quad SPI IP cores were configured to be in QUAD mode while the bootloader program expects it to be in Standard mode. This can be changed by re-customizing the IP. You also have to verify that in the project settings the bitstream configuration Bus width (under SPI Configuration) is set to 'NONE' and the Configuration Mode is set to 'Master SPI x1'. You can then generate the bitstream, export hardware, and launch SDK.

Following the rest of the  "How To Store Your SDK Project in SPI Flash" was successful after that. Everything seems to be working as expected.

Hopefully this helps others. Thanks again for your assistance! Let me know if you have any questions. 
 

Brad

[jpeyron]

Hi @bhall,

Glad to hear that you were able to get the flash project working! Thank you for sharing what you had to do to resolve the issue.

thank you,

Jon

 

[bhall]

Hi @jpeyron,

Unfortunately I am still having problems with this. I am now trying to create a similar project for a custom board. Because of this, I need to write my own XDC file for my specific device (XC7A100T-1CSG324C) rather than using the board file. I used the XDC provided by Digilent as a template. I believe that I have not configured QSPI correctly because when I run the SREC SPI bootloader generated by SDK it does not make it past the XIsf_Initialize() function. I used the debugging tool to investigate the problem here and it turns out that none of the device or manufactuer information is being passed to the IntelStmFlashInitialize() function. 

 

Is there any way you or someone at digilent could share a (preferably VHDL) project that uses a custom XDC rather than the board file? I think my issue and confusion stems from porting the signals in the project's top file to the external signals. I'm also getting confused by the IOBUFs that I may or may not need...

If any of this needs clarification or elaboration please let me know. I appreciate your help!

Thanks,
Brad

[jpeyron]

Hi @bhall,

Unfortunately, I am unaware of any Digilent VHDL or Verilog spi flash projects. Here is a thread that might help with using the QSPI Flash IP since i believe the Cmod A7 has a similar setup. I did find a very detailed blog How to build a SPI Flash Controller for an FPGA done by one of our community members @D@n.  Its in Verilog instead of VHDL but should be very helpful with getting your project going.

thank you,

Jon

[D@n]

@bhall,

You should thank @jpeyron for calling me out.  I tend to ignore any threads with block diagrams in them--I just don't seem to be able to contribute to them that well.

@jpeyron also cited the wrong reference to my article (Oops!).  I think he meant to cite this article here on flash controller development.  In general it's not really all that hard to do--you just need to spend some time working with the specification and your hardware, and a *really* *good* means of scoping out what's going on.  The design built in this article assumes a DDR output.  As such it can read a 32-bit word in (roughly) 72 system clocks.

I have an older QSPI controller as well that I've used on many of my flash designs.  It takes up twice as much logic.  The link above should show you where and how to find it if you would like.  This one doesn't use the DDR components.

The other trick in what you are attempting to do will require you to read an ELF file.  Check out libelf for that purpose.  It's really easy to use, and should have no problems parsing your executable file--before it turns into an MCS file.

Hope this helps,

Dan

[bhall]

@jpeyron and @D@n,

Thank you both for your responses and advice. I think the question I have now mainly applies to  the project that Jon provided. I am doing my best to make sure that my project has the same setting as yours does. I am confused about the qspi clock that is an output from the FPGA and is an input to the flash memory. It is not listed in the port map on the top level of your design, so is it inferred or constrained somewhere? In the Nexys 4 board file (and other documentation) I see that pin E9 is meant too be used for this purpose. Why is there no external port or pin visible for this in your project?

I am wondering if this is the reason why my srec spi bootloader cannot receive the device data from the flash itself. Since I am using a XDC file rather than the board file, is it possible that qspi_sck is not getting configured/connected correctly?

 

Hopefully this makes sense. Again, I really appreciate the help from both of you!

Brad 

[D@n]

@bhall,

No, this makes perfect sense.  Xilinx, in their infinite wisdom, created a SPI port clock pin to be used for configuring the device.  It's controlled internally.  When they then realized that customers would want to use it as well, they created a STARTUPE2 primitive that you need to use to get access to it.  As such, its often not listed in the port lists, but still usable.

On several of the newer Digilent designs, Digilent has connected that pin to two separate ports.  This allows you to control the pin like a normal I/O.  However, doing this requires special adjustments at the board level--not the chip level.

Dan

[jpeyron]

Hi @bhall,

Here is a forum thread that deal with the QSPI_CLK access on the Arty-A7 but not on the Arty-S7. I Also finished and verified the Nexys for project i Linked above and replaced it. If you were to re-download the program it would be the newer- finished program. I adjusted the qspi IP core to be similar to a recent project with the Cmod A7. Having the QSPI IP in standard mode and using SPIx1. I Also attached the board files for the Nexys 4 used by the newer versions of Vivado.  I would open the files in a text editor and look at the text. What are the differences between the Nexys 4 and your custom board in regards to pins?

cheers,

Jon

 

part0_pins.xml

board.xml

preset.xml