cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
508 Views
Registered: ‎03-19-2020

Programming external flash memory from microcontroller

Hi everybody,

I am redesigning a board with Xilinx Spartan 6 and a Flash SPI memory 8Mbit from Winbond.

I would like to understand how to program the external memory through a microcontoller that is onboard through SPI interface.

In particular three questions:

Which is the format that can be downloaded by microcontroller into the memory (mcs,hex) and in case there are multiple choice which is the best option in terms of file dimensions since the FPGA usage is very low and so the effective bit stream is much lower than memory capacity.

The sequence of the signals to put the FPGA in a state so to not disturb the SPI pins during this programming.

The sequence of the signals to trigger FPGA configuration.

I didn't find any application note or reference design on this specific case. 

 

Thanks in advance

Best regards

Max

0 Kudos
7 Replies
Highlighted
Xilinx Employee
Xilinx Employee
489 Views
Registered: ‎01-21-2008

Hi @MaxPerri 

 

We have AXI QUAD SPI IP (https://www.xilinx.com/support/documentation/ip_documentation/axi_quad_spi/v3_2/pg153-axi-quad-spi.pdf) which help you to access QSPI external Flash device in post configuration mode. Also we have Bare Metal s/w drivers (https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841745/Baremetal+Drivers+and+Libraries) for this AXI QUAD SPI IP  (https://github.com/Xilinx/embeddedsw/tree/master/XilinxProcessorIPLib/drivers/spi

Also have a look Xilinx application note Xapp1280 -> https://www.xilinx.com/support/documentation/application_notes/xapp1280-us-post-cnfg-flash-startupe3.pdf which is made for Kintex UltraScale (KCU105) board but it can be used for Sparta-6 device as well. (provided you do some changes in h/w design ^ s/w SDK design for Winbond flash )

Hope this helps.

Highlighted
453 Views
Registered: ‎01-22-2015

@MaxPerri 

Welcome to the Forum!

You’ll find that javhads has referenced ways whereby the file is first sent to the FPGA and then the FPGA sends the file to flash.  This is an alternative to the microcontroller method that you are considering.

However, for the microcontroller method…..

As a minimum (for SPIx1 communication) you probably need to control three inputs (CS, DIN, CLK) to the Winbond flash and be able to monitor one output, DOUT, (for readback and verification of stuff you write to flash).

Figure 2-2 of UG380 (v2.11) shows how the Spartan-6 is probably connected to your flash (you should verify).  If so, then to control the flash you need to prevent the microcontroller and the FPGA from battling for control of (CS, DIN, CLK).  Perhaps best to put switches on these lines.

The file that you write to flash is called the .bin version of the FPGA configuration (and not the .mcs version as most assume).  Typically, the .bin file is written to flash starting at flash address 0x00.

Since you have microcontroller experience, you probably know about bit-banging to implement SPI communication.  The Winbond datasheet will give command details of writing to this flash.  I don’t think you'll find any of this to be very difficult.

As a third alternative, consider the “Slave Serial” mode of configuring the Spartan-6 which uses a microcontroller and is described by Figure 2-3 in UG380.

Finally, if you are going to be writing configuration files to flash then you should think about how to recover from a corrupted configuration file.  For this, you might consider multiboot as described in Chapter 7 of UG380.

Cheers,
Mark

0 Kudos
Highlighted
Visitor
Visitor
409 Views
Registered: ‎03-19-2020

First of all thanks for your replies.

Just to clarify better we have a design in which microcontroller and FPGA share the Flash pins since we want that in case of future necessity we can update the FPGA memory through the microcontroller. In normal conditions memory program is loaded by PCBA supplier directly and it's never changed.

Coming back to my 3 questions that refer only to the future necessity scenario so the first answer is that it's not the mcs format to be downloaded by the microcontroller but the bin format if I have understood well.

What about the second question, i.e. which is the right sequence to program the memory putting the FPGA in a state so to not interfere during memory programming?

Best regards

Max

 

0 Kudos
Highlighted
Scholar
Scholar
394 Views
Registered: ‎05-21-2015

@MaxPerri,

Back up a moment ... are we talking about an external microcontroller?  Not a Microblaze design where the micro is part of the FPGA logic, nor a Zynq design where the micro is part of the die itself, but a physically separate microcontroller?

In that case, you'd need to make certain that the FPGA set the various SPI pins to a high impedence before trying to program them from the micro.  You might even need to use a hardware pull up in case there's ever a question of what the voltage value will be when one of the two isn't operating.

I'll look forward to hearing from the moderators whether or not such a solution is supported by the AXI Quad SPI controller.

Dan

0 Kudos
Highlighted
387 Views
Registered: ‎01-22-2015

@MaxPerri 

Which is the format that can be downloaded by microcontroller into the memory (mcs,hex)..
The bin format is needed.

The sequence of the signals to put the FPGA in a state so to not disturb the SPI pins during this programming.
Please see Table 2-2 in UG380(v2.11), which lists the FPGA pins of the Spartan-6 that are used to communicate with flash.  If the pin is listed as “Dual-Purpose” then you can specify the pin to be an input in the usual way.  After the FPGA has finished using the pin to read the configuration file from flash, the pin will be configured to be an input (as you have specified) and will not interfere when the microcontroller tries to communicate with the flash.  However, if a pin in Table 2-2 is listed as “Dedicated” then you cannot configure the pin and it may interfere when the microcontroller tries to communicate with the flash.

The sequence of the signals to trigger FPGA configuration.
Cycling power to the board is one method.  Also, your HDL for the FPGA can use ICAP and the IPROG command to force reconfiguration of the FPGA from flash.  See “IPROG  Reconfiguration” on page 136 of UG380.

Please read AR#70681 and verify that Xilinx has approved your Winbond flash for use with iMPACT and the Spartan-6.

…we have a design in which microcontroller and FPGA share the Flash pins since we want that in case of future necessity we can update the FPGA memory through the microcontroller.
When updating the configuration file stored in flash, it is more common to either: 1) send the file directly to the FPGA and use HDL in the FPGA to then write the file to flash, or 2) use the “Slave Serial” mode of configuring the Spartan-6 which uses a microcontroller and is described by Figure 2-3 in UG380.

Mark

0 Kudos
Highlighted
Visitor
Visitor
322 Views
Registered: ‎03-19-2020

Just as clarification my request is for programming flash by an external separate microcontroller, not a microcontroller embedded in FPGA and not during FPGA functioning but at power up, si I can put FPGA in a state not to interfere during Flash programming.

For this last reason I was thinking to put the FPGA in a state so to have all pin 3-stated so that there will be no issue while microcontroller will program flash.

I found at the following link (https://forums.xilinx.com/t5/FPGA-Configuration/INIT-B-on-Spartan-7-FPGA-in-reset/td-p/1026452) a sequence to program the flash through microcontroller by setting the following pins:

1. Hold INIT_B low

2. Program flash

3. Release INIT_B

4. Pulse PROGRAM_B low

Does this sequence work also on Spartan 6? Or which is the right sequence?

Thanks

Max

 

 

 

Highlighted
304 Views
Registered: ‎01-22-2015

@MaxPerri 

Does this sequence work also on Spartan 6? Or which is the right sequence?

Page 42, Table 2-6, UG380(V2.11) says, "Drive PROGRAM_B Low and release to reprogram FPGA. Hold PROGRAM_B to force the FPGA I/O pins into High-Z, allowing direct programming access to SPI flash pins."

Mark

0 Kudos