• 0
Sign in to follow this  
David1234

Reading and writing to QSPI on the CMOD A7

Question

Hi,

I want to use the left over flash memory that the bin file isn't using to store data.

  1. Is there an example of this being done? I haven't been able to find one.
  2. 5 ports are exposed on the CMOD A7 for this: qspi_cs and qspi_dq[0:3]. Can I use a SD card controller to write to the internal Flash like this one https://github.com/xesscorp/VHDL_Lib/blob/master/SDCard.vhd?

-David

 

Share this post


Link to post
Share on other sites

5 answers to this question

Recommended Posts

  • 0

@David1234,

I use the QSPI flash controller found here on opencores.  I've used this in almost all of my Digilent projects.  Here's a generic example project using this controller, to include a software controller that I use for programming the flash.

An SD-Card controller will not work.  The SD card controller uses a single wire for a bi-directional command control, and then four data lines.  The four data lines are always inputs, or always outputs, based upon the command given over the bi-directional command wire.

QSPI flash is completely different--there are only four data wires.  Unlike SD, there's no extra command wire.  Further, you have to carefully control when you are in four wire mode and when you are in standard SPI mode.

Dan

Share this post


Link to post
Share on other sites
  • 0
9 hours ago, D@n said:

@David1234,

I use the QSPI flash controller found here on opencores.  I've used this in almost all of my Digilent projects.  Here's a generic example project using this controller, to include a software controller that I use for programming the flash.

An SD-Card controller will not work.  The SD card controller uses a single wire for a bi-directional command control, and then four data lines.  The four data lines are always inputs, or always outputs, based upon the command given over the bi-directional command wire.

QSPI flash is completely different--there are only four data wires.  Unlike SD, there's no extra command wire.  Further, you have to carefully control when you are in four wire mode and when you are in standard SPI mode.

Dan

Thanks Dan. I saw that entity earlier but discarded it thinking it wouldn't work because the interface didn't seem to match up.

  1. Would eqspiflash.v be the top level in a simple, non-softcore-cpu CMOD A7 project?
  2. I essentially just want to use this as a really slow memory where I just provide a WR/RD signal, address and data signals. For some reason the CMOD A7 has qspi_cs and qspi_dq[0:3] but no qspi_clk... Is the clock from something else automatically used?
  3. In general, what changes need to be made to use this in a simple, non-softcore-cpu CMOD A7 project?

Thanks,

   David

Share this post


Link to post
Share on other sites
  • 0

David,

  1. eqspiflash.v would be the top-level flash component.  I suspect you will have other components within your design.
  2. You may need to instantiate the STARTUPE2 primitive to get access to the output clock.  Since it's shared between Xilinx's load logic, you need to do a little extra work to control it.
  3. To request a transaction with the core, set (i_wb_cyc)&&(i_wb_stb).  You'll also want to set the address (zero is the beginning of the flash).  If you wish to write to the core, set (i_wb_we) and the data you wish to write.
  4. The core will control the (o_wb_stall) flag.  When (i_wb_cyc)&&(i_wb_stb)&&(!o_wb_stall), a transaction request has been accepted.  Drop the i_wb_stb line on the next clock, lest you request multiple transactions when you only want one.  (Or keep it raised, and just set the next address ...)
  5. The core will respond to your transaction request (eventually) by setting the o_wb_data and o_wb_ack lines.  At that time, any read data is ready.  You can drop   i_wb_cyc after you get the ack from your last request.  If you drop i_wb_cyc early, the ack will be suppressed.
  6. You can find an example wishbone master here, or a discussion of how to build one here.
  7. If this is still confusing, check out Fig's 3-6, 3-8, 3-11, and 3-13 of the wishbone spec, version B4.  This core, as with all of my cores, uses the pipelined version of the spec.

Remember, this is a flash: reading is easy.

Writing is harder.  There are two steps to any write to a flash.  The first is to set any '0' bits to '1's.  This is called erasing.  You can erase sectors or subsectors, but sadly you cannot erase pages, words, or even bytes.  Erases are therefore rather heavy handed.  To command an erase, (check the doc's within the core) you'll write to the write protect word in the controller to turn off write protection.  You'll then write to this word (again) with the erase command and the address of the area you wish to erase.  The flash device will then go out to lunch for many ms (I think the spec says up to 3s), to do this erase.  During this time, you can read from the status register of the core to know if it is done or not.  Alternatively, once the erase is complete the core will raise an interrupt flag so you can tell it's ready to be used again.  The core will turn the write protect flag back on when it is done.

That's erasing.

The second step to writing.  This is the step that you use to turn '1's to '0's.  The flash specification calls this "programming".  To program a device with this core, first write to the control register to turn off the write protect bit.  You can then write to a "page" containing 256 bytes.  Do as instructed in the steps above, but also ... write consecutively from one value on the page to the next.  The core, and indeed the flash itself, can't handle writes that jump around on the page.  Second, keep the i_wb_cyc line high.  Once that line goes low, your page write request will be complete, and the device will go off and write.  Expect this to take several ms as well.  As before, you can either read the status register from the core to know if/when it is done, or you can wait for the interrupt line to go high.

If you've never worked with flash memory before .... <grin> it's not like regular memory.  Hopefully you understand that by now.  While you can treat reading from a flash device like reading from a slow ROM, writing to the device is much harder--so hard that most applications just treat the device like a ROM.  Still, it's good for storing configuration data within it.

Hope this helps,

Dan

Share this post


Link to post
Share on other sites
  • 0
16 hours ago, D@n said:

David,

...

Hope this helps,

Dan

I want to use the remaining flash memory to save user settings so that the user's settings persist even if power is lost. Is saving their settings to flash as they are changed the most practical way to save their settings, or is there a smarter, easier way to accomplish the same thing?

Share this post


Link to post
Share on other sites
  • 0

@David1234,

If your goal is to have persistent memory, the flash is usually the way to go.  While it is possible to use an SD card for the same thing, SD cards take a lot of interaction with their host just to set up.  Your other alternative would be to send information from the host (i.e. your PC) to the FPGA.

If you have to write flash, there is one thing you *must* ensure, and that is that power cannot be removed from the flash mid-erase or mid-write operation.  The problem is that, if power gets pulled, the flash may act right and it may not act right with a random probability. It may act right once, and then not the next time, etc.  This has been a thorn in the side of those making flash-based devices, such as thumb drives.  The software can come through checking CRC's, and sectors 1-N might pass, so software may declare those sectors good--only to have one of them not-pass later.  The same would be true of an SD-card--don't pull power mid-write.

The other (easier/simpler) alternative would be to pass the device its configuration from a host machine upon startup.  Of course ... that only works if your device will be running in a situation where that's possible.  In this case, you'd need to pick some sort of protocol to pass this information along.

There are lots of possibilities, I guess.  Pick the one that's right for you.

Dan

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
Sign in to follow this