cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
14,093 Views
Registered: ‎02-05-2016

SPI Flash Spartan 6 Readback

Jump to solution

Hello, I am trying to readback from a SPI flash connected to a Spartan 6 FPGA using JTAG interface. Within the Readback Options of the Process Properties for Generate Programming File, Security is set to Enable Readback and Reconfiguration and Create ReadBack Data Files is checked. From there I open up Impact and program the newly generate .mcs file to the flash. Upon completion the FPGA and I/O works as desired; for smplicity let's say I have a simple push button that can switch on and off an LED.

Now I readback from the flash storing to a temporary .msc file. When starting readback the FPGA and I/O is no longer functional; I can't switch the LED on and off. Impact informs me ReadbackToFile Succeeded. Upon completion I still can't use the I/O and need to power off and on the setup for the I/O to function again. I know the readback was successful though because I can program the temporary .msc file to the flash and it works as expected. So I guess my concern is how to control what is going on in the FPGA while performing a readback.

By glancing over the UG380 User Guide file page 116 mentions "readback is possible while the FPGA
design is active or in a shutdown state." Is there a property in the GUI or elsewhere that I can use so that the I/O remains functioning while a readback is being performed; i.e. can I toggle on and off the LED while a readback is being performed and upon its completion without requiring a power down.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Professor
Professor
24,269 Views
Registered: ‎08-14-2007

Re: SPI Flash Spartan 6 Readback

Jump to solution

The default for the indirect SPI access core is to pull up all "unused" IO pins.  In this context "unused" is everything that the SPI core itself doesn't use, so pretty much all of the IO.  Spartan6 does have a PUDC (pull-ups during config) pin which when pulled up or allowed to float will turn off pull-ups during device config.  However that doesn't help during the time the indirect SPI access core is loaded.  I have seen other threads where people have requested a SPI access core with unused IO set to float instead of pull-up.  That could be an option for IO's like your BJT.  It's unfortunate that the "float" version of the cores is not generally available.  For 7-series and newer parts, Vivado allows you to select whether pins are pulled up or floating during indirect programming, but again that doesn't help you with Spartan 6.  As for direct SPI programming, it has been dropped from newer versions of ISE Impact.  However if you have access to the SPI pins on a header, and have a way to make sure the FPGA is not driving them during programming, there are a lot of 3rd party devices for programming SPI flash which are generally inexpensive and much faster than programming indirectly.  One way to keep the FPGA from driving the SPI lines is to assert PROG_B low.  After programming is complete you can release PROG_B and the FPGA will configure from flash.  In a design that doesn't access the SPI after configuration, you can just leave the related pins out of the design and they will default to your unused IOB setting (pull-up, pull-down, float, or drive low).  Pull up would be the best option if you want to program the SPI directly while your design is loaded.  Of course all of this requires access to the SPI flash control lines by an external device.

-- Gabor

View solution in original post

0 Kudos
11 Replies
Highlighted
Professor
Professor
14,059 Views
Registered: ‎08-14-2007

Re: SPI Flash Spartan 6 Readback

Jump to solution

If your design has code to read the SPI flash, then "readback is possible while the FPGA design is active," however this statement does not apply to using JTAG to read the SPI flash with Impact software.  Impact does not use the boundary scan chain to do the indirect SPI access.  Instead it loads its own bitstream into the FPGA as a "helper app" to manage the SPI interface.  This obviously means that your own design is no longer running and you have no control over the I/O.  Furthermore, when you do something other than program the attached SPI flash with Impact (like reading it out to a file) Impact will leave the SPI access core loaded in the FPGA in anticipation of further use rather than reloading your bitstream.  That's why you needed to re-power the board (or you could have re-loaded the FPGA via JTAG or by pulling PROG_B low momentarily).

 

-- Gabor
0 Kudos
Highlighted
Visitor
Visitor
13,461 Views
Registered: ‎02-05-2016

Re: SPI Flash Spartan 6 Readback

Jump to solution

Thank you Gabor; that clarifies things. You mentioned that the user has no control over the I/O which makes sense based on your explanation. My next question is what the "helper app" does to the I/O pins (both that were used and unused in the original design). Are they floating, pulled-up, pulled-down, ..., and is there any way to specify what happens to them? I ask this because in a design one of the I/O's is connected to the base resistor of a BJT. Prior to readback/programming and following programming the BJT at its base measures 0V; its off. During the readback/programming though the BJT at its base measures around 0.7V; its turned on. For clarification this is with nothing connected to the collector and the emitter grounded. To verify, a piezo buzzer was connected to the collector of the BJT, and it sounds during programming and readback since the "helper app" is running. Since it was buzzing it means the BJT was turning on and off which leads me to be a bit confused regarding the state of the I/O during configuration.

I've been reading through the documentation relating to Spartan 6 as well as Xilinx Application notes. I'll try to summarize what I have found so far; hoping for guidance in the right direction.
Based on XAPP176 pg.1 it seems that I could have "controlled" the I/O during configuration using pins M0, M1, and M2 to either floating or pull-up, but this isn't applicable for Spartan 6 devices; there's only M0 and M1 (My Spartan 6 is set for Master Serial; M0 pulled high, M1 grounded, and the Vcco's are 3.3V).
XAPP951 p.19 goes into direct SPI programming using impact which would have overcome the problem mentioned above during programming though its no longer applicable.

XAPP102 requires XPS which I do not have a license to. XAPP058 requires a microcontroller/microprocessor which is not in my current design.

So basically to sum things up I have a single Spartan 6 FPGA (FTG256 LX9) and only ISE access. Based on this limitation is it possible to program and readback from a SPI flash using Impact without interfering with the original configuration of the FPGA and its I/O's; it seems that the answer is no. Can I "control" how the I/O are handled during configuration similar to what was mentioned in XAPP176? Thank you for your time.

0 Kudos
Highlighted
Professor
Professor
24,270 Views
Registered: ‎08-14-2007

Re: SPI Flash Spartan 6 Readback

Jump to solution

The default for the indirect SPI access core is to pull up all "unused" IO pins.  In this context "unused" is everything that the SPI core itself doesn't use, so pretty much all of the IO.  Spartan6 does have a PUDC (pull-ups during config) pin which when pulled up or allowed to float will turn off pull-ups during device config.  However that doesn't help during the time the indirect SPI access core is loaded.  I have seen other threads where people have requested a SPI access core with unused IO set to float instead of pull-up.  That could be an option for IO's like your BJT.  It's unfortunate that the "float" version of the cores is not generally available.  For 7-series and newer parts, Vivado allows you to select whether pins are pulled up or floating during indirect programming, but again that doesn't help you with Spartan 6.  As for direct SPI programming, it has been dropped from newer versions of ISE Impact.  However if you have access to the SPI pins on a header, and have a way to make sure the FPGA is not driving them during programming, there are a lot of 3rd party devices for programming SPI flash which are generally inexpensive and much faster than programming indirectly.  One way to keep the FPGA from driving the SPI lines is to assert PROG_B low.  After programming is complete you can release PROG_B and the FPGA will configure from flash.  In a design that doesn't access the SPI after configuration, you can just leave the related pins out of the design and they will default to your unused IOB setting (pull-up, pull-down, float, or drive low).  Pull up would be the best option if you want to program the SPI directly while your design is loaded.  Of course all of this requires access to the SPI flash control lines by an external device.

-- Gabor

View solution in original post

0 Kudos
Highlighted
Scholar
Scholar
13,177 Views
Registered: ‎06-05-2013

Re: SPI Flash Spartan 6 Readback

Jump to solution

@mdmottola Yes, you are right. IOs are being pulled up during readback because of spi flash controller. Do you have a SR access? If yes please file a service request to get the spi flash controller version for pull none or pulldown. If you do not have access let me know.

-Pratham

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
12,650 Views
Registered: ‎02-05-2016

Re: SPI Flash Spartan 6 Readback

Jump to solution

Thanks Gabor. Say I decide to take the approach of programming the SPI flash through a second header. As discussed when performing indirect programming, I've generated an MCS file to be sent to the SPI flash through the FPGA using the SPI flash controller or "helper app." Correct me if I am wrong but if I directly read from the SPI flash using its associated command set the bitstream I read back will not match the MCS file; the MCS file has other checks associated with it. If I wanted to go about bit-banging my FPGA project to the SPI flash using its associated command set I should generate a BIN file. With a single FPGA in Master Serial/SPI mode, I'm assuming the FPGA during device configuration upon power up expects the first bit in the BIN file to start at the least significant memory location of the SPI flash; or is this also dependent on the SPI flash being used (Micron M25PE80)?

0 Kudos
Highlighted
Visitor
Visitor
12,649 Views
Registered: ‎02-05-2016

Re: SPI Flash Spartan 6 Readback

Jump to solution

Hello Pratham, I don't believe I have SR access, and if I do I've never used it before. Just for clarification purposes when you say pull none the pins are floating as Gabor described?

0 Kudos
Highlighted
Scholar
Scholar
12,629 Views
Registered: ‎06-05-2013

Re: SPI Flash Spartan 6 Readback

Jump to solution

@mdmottola Yes, Floating one. Since you dont have SR access,I will send you an email with the detailed steps.

Hopefully this will resolve the problem.

-Pratham

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Professor
Professor
12,597 Views
Registered: ‎08-14-2007

Re: SPI Flash Spartan 6 Readback

Jump to solution

While the MCS file has additional information besides the data, its format is a standard and likely to be supported by other software like third party PROM programmers.  If the only thing you placed in flash is your bitstream, then its data contents should match the .bin file.  For systems that have additional data like .elf files stored in the flash you would also need to provide that data to the programming solution.  The MCS format is published, so even if you decided to write your own program to load the flash from the MCS file, it would not be too difficult.  One of the advantages of MCS over a pure binary file is that when you have gaps of unused PROM area the file does not need to contain data for those areas, which can speed up programming when for instance you have a large gap between the end of the bitstream and the start of the .elf file.  Gaps are common in flash applications where it makes sense to start a new file on an eraseable block boundary to avoid having to re-write other data when you erase that block.

-- Gabor
0 Kudos
Highlighted
Visitor
Visitor
12,457 Views
Registered: ‎02-05-2016

Re: SPI Flash Spartan 6 Readback

Jump to solution

Thank you Gabor and Pratham for all your help!

0 Kudos
Highlighted
Scholar
Scholar
9,471 Views
Registered: ‎06-05-2013

Re: SPI Flash Spartan 6 Readback

Jump to solution

@mdmottola Did you get the core file sent to you? did that helped you to solve the problem?

-Pratham

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
9,452 Views
Registered: ‎02-05-2016

Re: SPI Flash Spartan 6 Readback

Jump to solution
Hi Pratham,
Yes I got the file, and it works as expected. The I/Os such as the one tied to the BJT mentioned before no longer trigger. When performing SPI flash operations through Impact. I'll use this as a temporary solution and eventually will develop my own solution using say a secondary header directly to the SPI flash and FPGA code to allow for direct programming while the system and I/O are still in operation similar to what Gabor has touched upon.
Thanks again!
0 Kudos