• 0
Dean@L3

Digilent tutorial "How To Store Your SDK Project in SPI Flash" question

Question

20 answers to this question

Recommended Posts

  • 0

Hi @Dean@L3,

Welcome to the forums! I believe we used Vivado 2015.4 to create the "How To Store Your SDK Project in SPI Flash" tutorial. We have added an updated for Vivado 2017.1 in section 4.1 about the flash type being different for the Arty in Vivado 201701.  

cheers,

Jon

Share this post


Link to post
Share on other sites
  • 0

Thank you.  I'm trying this with 2016.3 so hopefully it's close enough.

In the tutorial at 1.3 it states "If you are using the Cmod-A7 and you did not compressed your bitstream try the offset: 0x00300000."

I'm trying this out on a Cmod-A7.  What is a reasonable address if you did compress it?  (Maybe I'm missing something obvious here?)

Share this post


Link to post
Share on other sites
  • 0

Hi @Dean@L3,

I have used Vivado 2016.4 with the Cmod A7 using this tutorial with out an issue. Unfortunately, i have not used a compressed project with this tutorial before. I would suggest to use the FLASH_IMAGE_BASADDR that is in the file initially.  If that address does not work I would suggest to use the  0x00300000. I will go through the tutorial using a compressed project with the Cmod A7 and get a good address for you tomorrow. 

cheers,

Jon

 

Share this post


Link to post
Share on other sites
  • 0

Hi Jon,

I created (using 2013.3) a simple new project today to try this out again.  It's the "hello_world" project from the "Cmod A7 - Getting Started with Microblaze" tutorial.  To this I added the quad spi IP from the board tab to this project BD.  Everything in this tutorial runs fine.  Using this project as a starting point I followed everything in the "store in flash" tutorial very closely.  Unfortunately, my result is always the same that I cannot program the flash on the CmodA7.  I get the following response:

>Connected to hw_server @ TCP:127.0.0.1:3121
>Available targets and devices:
>Target 0 : jsn-Cmod A7 - 35T-210328A4172FA
> Device 0: jsn-Cmod A7 - 35T-210328A4172FA-0362d093-0

>Retrieving Flash info...

>ERROR: Flash Operation Failed

I did notice one thing that seemed odd in that when I ran the Program FPGA step with the bootloader just before the Program Flash, I got "Blink World" on the terminal.  Perhaps that's just what it does. 

I've tried doing this several times before and always get stuck at the program flash part.  At this point I'm lost as to what to do next or what I'm doing wrong.  I've included the image of the programming step below.  Any help you can provide on this would be greatly appreciated!  Thanks. 

Dean

Prog_App.jpg

Share this post


Link to post
Share on other sites
  • 0

Never mind about the part where I said "...Program FPGA step with the bootloader ... I got "Blink World"..."  Apparently I had managed to get code into the flash at some point and this was executing when I did the Program FPGA step at 3.1.

There's something wrong with the Program Flash function in 2016.3.  I recreated the project in 2017.2 and the Program Flash function works there. 

After programming the flash in 2017.2 as in sections 4.1 and 4.2 I tried unplugging the CmodA7 then plugging it back in again to reset it but nothing comes up on the terminal.  In SDK run debug this works. This brings up the flash erase operation.  It appears to erase the entire flash.  If this is so then the elf file that I programmed first would no longer be there after the second program flash step where I programmed in the bootloader.  But the tutorial said that this works.  What am I missing? 

Share this post


Link to post
Share on other sites
  • 0

Hi @Dean@L3

I am researching if there is a better address when the bitstream is compressed. I was able to get my compressed bitstream to load on the Cmod A7-35 in Vivado 2016.4 without an issue. In Vivado make sure to have the Microblaze configured with the local memory to 32k and the cache at 16k.  Also make sure that you are updating the blconfig.h located in src's and change FLASH_IMAGE_BASEADDR to 0x00300000 as well. I will go though it in Vivado 2017.2 and see if I have issues.

cheers,

Jon

Share this post


Link to post
Share on other sites
  • 0

Hi @Dean@L3,

I was able to get the tutorial to work in Vivado 2017.2 as well. To make sure that it was not from a previous project it used the this tutorial to load the flash with a different working project. Then I went through the turorial in Vivado 2017.2 with no issue. I used the FLASH_IMAGE_BASEADDR as 0x00300000. Also in Vivado make Microblaze configured with the local memory to 32k and the cache at 16k. Also just to clarify you are using the board files that is part of the prerequisites in the Getting Started with Microblaze tutorial. The board file tutorial is here. Also what OS I.E. windows, linux.. are you using?

cheers,

Jon

Edited by jpeyron

Share this post


Link to post
Share on other sites
  • 0

It's still not working and I'm really trying to follow this to the letter.  I appreciate you hanging in there with me on this. 

I went back and recreated the hardware insuring that it had the local memory set to 32k and the cache at 16k.  Previously I had it set to local memory set to 64k and the cache at 8k.  I'm am using FLASH_IMAGE_BASEADDR as 0x00300000.  I cleared out the code in SDK and started that over.  When I run it in the SDK debugger it runs and presents on the terminal so the code must be working but this worked for me earlier too. 

1. How are you resetting the CmodA7?  I'm pulling the USB then reinserting. 

2. How is it that we program twice and the second time doesn't erase what was programmed on the first program step?  (It indicates erase and blank check.)

Thanks,

Dean

Share this post


Link to post
Share on other sites
  • 0

HI @Dean@L3

I am pulling the usb cable out and plunging it back in. For your second question, are you talking about the section 4 Program Flash of the tutorial where we program two different sections of the flash? One part of the flash is programmed with the hello_world.elf  with the offset of  0x00300000 and the other part is programmed with the download.bit starting at 0x0. 

cheers,

Jon

 

Share this post


Link to post
Share on other sites
  • 0

That's what I was doing, pulling the USB cable out and plunging it back in.  Just checking, I was thinking that perhaps the USB-UART device or the PC driver might have not been up and running in time to catch the "hello world" on the terminal. 

Yes, section 4.  I'm using those offsets, 0x00300000 for the hello world elf and 0x0 for the boot loader bit files.  How is it that the whole flash is not erased each time?  Is there a setting to control this that I might have missed?  Each time it tells me that it did a blank check. 

And just to be sure, download.bit is at:  Proj_Name/Proj_Name.sdk/Proj_Name_wrapper_HW_Platform_0/download.bit, is that correct? 

Share this post


Link to post
Share on other sites
  • 0

Hi @Dean@L3,

I believe that the erase is only for the region of the flash that you are putting in new data as described here and not the whole flash. The path name looks correct.  Are you using tera term as the serial terminal? I suggest using the getting started with microblaze tutorial for building the block design in vivado. The only two differences is when you are configuring the output clocks in the clocking wizard I also add a 50 MHz clock and when adding the uart I also as the axi quad spi. I then add the 50 MHz output clock from the clocking wizard to the ext_spi_clk on the axi quad spi IP core.  Can you attach a screen shot of you block design from Vivado?

cheers,

Jon

Share this post


Link to post
Share on other sites
  • 0

Hyperterm.  Since it seems to work in SDK debug I would imagine that is not the issue. 

It says "The contents are read back and check if the region erased is blank" which is most ambiguous but if that works for you than it must be only a partial erase.  I'll not worry about this one any more. 

I'm using the "getting started with microblaze tutorial " and adding the spi IP.  I'll add in the 50MHz clk that you mentioned and try that.  I had it tied to the AXI clk at 100MHz.  BTW, I'm using the n25q32-3.3v-spi-x1_x2_x4 for the flash type and giving the type a 5 as it says. 

BD screen shot attached and also I've attached the SDK log during my programming of the flash. 

BTW, I sure do appreciate you staying with me on this! 

SDK.log

BD.jpg

Share this post


Link to post
Share on other sites
  • 0

I'm building the "50MHz clk" into the design right now but just one more thing for today...

Was I supposed to flash the hardware bitstream in Vivado before the two program events in SDK?  I assumed that the boot loader was combined with the hardware in the download.bit. 

Share this post


Link to post
Share on other sites
  • 0

Tried the "50MHz clk", same thing.  Do I need to shut down the tools?  I see a lot of communications with the module com led but nothing on the terminal.  Also strange, the done led is on immediately at USB plug in. 

Share this post


Link to post
Share on other sites
  • 0

@Dean@L3,

I would make a fresh project using the 50 Mhz clock from the clocking wizard  connected to the ext_spi_clk on the quad spi ip. You are able to run the hello_world application an set it in the terminal correct? Tomorrow is will add my project to google drive and see if you can run it.

cheers,

Jon

 

Share this post


Link to post
Share on other sites
  • 0

Yes, It still runs under SDK debug run with the correct message showing up on the terminal. 

I'll start over with a new project and include the 50MHz ext_spi_clk and see what happens.  This will be about the 6th time I've started this new. 

Share this post


Link to post
Share on other sites
  • 0

Success, finally, although there are several things to note. 

It would appear that upon plugging the USB into the PC, the terminal program was not catching the communications.  I was using HyperTerminal and found that it would miss the initial message but upon doing a disconnect-reconnect, it would then see receive data that was delayed from the CmodA7.  In this latest build I added in blinking LEDs and several delayed messages to the C code so that I could see activity both ways.  I also tried this with TerraTerm but it acted the same way. 

I added BTN0 as a reset.  This allowed starting the program over without the USB disconnect-reconnect.  On pressing BTN0 reset, all of the print messages appeared on the terminal.  Of course the LEDs always blink to tell me that the thing is working whether I see info on the terminal or not.  I'll attach the code and the BD image. 

This version has the 50MHz ext_spi_clk.  Whether that made a difference I can't say.  I know the hardware is working with this and flash programming is obviously working too.  

Now when I plug the USB in the DONE LED takes several seconds to come on.  On previous try's it came on immediately.  That's probably telling but I don't know what was different before to cause that.   

Two other things:  This time I used xil_printf() instead of print.  I believe the amount of code generated is less this way.  Also, I did not compress the image.  The MicroBlaze has 32k of local memory and 16k Cache as you directed earlier. 

I'm not sure what thing(s) made this work now but obviously there are a number questions still lingering.  The problem is that it takes a long time to try this and then try that with proper scientific method and I've already spent way too long just getting to this point. I really need to move on and get some other things going here.  At least I have a good starting point now to do that.  Thanks for all of your help with this Jon! 

 

BD.jpg

helloworld.c

Share this post


Link to post
Share on other sites
  • 0

This is just follow up:

I found that if you disconnect with the terminal program before plugging the USB cable back in and then reconnect right after plugging in the USB cable, all of the messages get presented.  This way it seems to be ready before the FPGA DONE LED is presented.

Considering the actual amount of the room in the flash that is required for the 35T FPGA load, an offset of 0x00218000 can be used to maximize the flash space that will still available for program code.  This is 48% of the N25Q032 flash whereas the offset of 0x00300000 only leaves 25%.  Again, I did not compress my image.  I did program this new offset into blconfig.h and used it in the elf program flash step just to test it out and insure that it still worked. 

 

jpeyron likes this

Share this post


Link to post
Share on other sites
  • 0

That offset might be better off being 0x00220000.  I don't know whether Xilinx utilizes the sub sector erase but using this offset would be safe if it only uses sector erase. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now