• 0
Dean@L3

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

Question

21 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. 

 

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
  • 0
Posted (edited)
On 20/9/2017 at 10:42 PM, Dean@L3 said:

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. 

 

Hi, I'm same trouble in my design with VIVADO 2017.4, following your last suggest I can see into the terminal only a first row and then nothing about the rest of the messages from the bootloader.

issue.jpg.640c9c25dc9e5fca8115cd14907c1479.jpg

But if I run into the Xilinx System Debugger I can see all the booting messages and the system is able to work properly.

dbgok.jpg.1c8428a8cece4206995648ad4770cde2.jpg

Do you have some advice?

I'll be gratefully for any help on this subject.

Thanks.,

UPDATE

To be sure about the steps I've did again all the steps with VIVADO 2016.1 design and all is working properly, the bootstrap process run fine hence seems somethings related to the VIVADO 2017.4. Also may be due to the importing from the 2016.1 but this seems strange to me because into VIVADO 2017.4 the simulation (GDB and Xilinx System Debugger) run fine without any trouble and also If I try the System Debugger I'll able to see the boostrap process with whole messages...

UPDATE

Hi again, under the suspect that there are some things related the import task from VIVADO 2016.1 to the VIVADO 2017.4 I've completely delete the content of the .sdk folder that is into the main design folder.

Then, from VIVADO I've exported the hardware with bistream included and then I've launched the SDK.

The SDK is empty, so I've rebuild all things following the tutorial starting from the creation of the SPI Bootloader Application and so on, at the end of the process all things was able to work then if anyone got same problem my suggestion is to delete all the contents inside the .sdk folder and performs again starting from scratch all the tutorial steps.

Debugging with the DBG and the System Debugger are corrects but I'm unable to booot from the SPi Flash, when the USB cable was unplugged and then inserted again into the terminal I can see only the first line of the bootloder "SREC SPI Bootloader", and then no activity on the serial as the process is blocked.

UPDATE

I've rebuilded from scratch the whole design inside VIVADO 2017.4.1 but at the end of the story the result is the same, the SPI storing is not working anymore...

UPDATE - WORKING BOOTLOADER!!

STEP 1

I've rebuilded again from zero the whole design into VIVADO 2017.4.1 but now I've followed carefully all the steps listed inside the tuturial:

"Cmod A7 - Getting Started with Microblaze" (LINK)

on the web site there is a indication that is obsolete but for me have solved every issue.

In my flow I've only two differences regarding what is shown into the tutorial: one is about the Microblaze configuration (see below, I've followed the values listed in this thread from @jpeyron and changed the default ones)

Tacho-microblaze-settings.jpg.17e08682f5b39f06143eb0f615cf5cde.jpg

and the QSPI Flash that is added as last pheriperal just after the USB UART (see below).

As written above the second difference is that after putting the USB UART, as explained into the step 5.1 of the cited tutorial, you have also to insert into the Block Design the QSPI Flash from the board tab and then perform the Run Automation All task as specified into the tutorial at the step 5.2.

Despite this little difference follow the rest of the tutorial until you reach the step 8.1, make the hardware exporting with the bitstream included and stop a moment.

It seems to me, from all the tests that I've did, that is more important execute the Run Automation task exactly at the point specified into the tutorial (step 5.2), into my previous design, also started from zero, I've performed this task after putting some IP block, then too soon regarding the flow shown into the tutorial, and this may be have corrupted or changed my final design into a way that the bootloader was not able to work properly but able to work only under debugging.

At this point I strongly suggest to perform the archive project action in order to have a fresh copy of the design for future reference before starting the SDK work.

After the backup finish make the step 8.2 and then run the SDK, the first part is finished.

STEP 2

Now you are into the SDK, wait a little that the workspace is builded from the hardware description that is automatically imported from VIVADO.

Now you have basically to follow every steps listed into the following tutorial:

"How To Store Your SDK Project in SPI Flash" (LINK)

As a side note I've not followed the first step "0. Compress Bitstreams (Optional)" I therefore jumped directly to the next step "1. Create a SPI Bootloader Application".

Into the "2. Create User Application" section I've only changed the printf statement with the xil_printf into the helloworld.c source.

For the Cmod A7-35T board you have also to skip the step 2.3 (thank @jpeyron).

From this point until the end of the tutorial follow all the listed steps, just take care of the right flash type option when you have to perform the Program Flash task, for the Cmod A7-35T select the n25q32-3.3v-spi-x1_x2_x4 memory model.

There are exactly the full procedure that I've followed to get all working, the pdf of my design is also attached to this post in order to use it as reference and check if your Block Design schematic looks like mine.

 

I hope this informations will be useful for other people that get trouble to have the bootloader properly working with the Cmod A7-35T.

Let me know if somethings is not clear and I'll try to explain it better.

Best regards

system.pdf

Edited by BYTEMAN
SOLVED - BOOTLOADER IS WORKING!!

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