cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
12,020 Views
Registered: ‎03-02-2015

Quickboot failure 256 Mb SPI x1 for Kintex7

I have a Kintex 7 design built in Vivado 2015.1  

The .bit file is 15.5 MBytes.  I can convert it to an MCS and successfully program a N25Q256 flash memory and boot from it.  This works with 24-bit and 32-bit SPI addressing.

 

I need to use the QuickBoot method to allow the flash to be updated in the field.

 

I use the the MakeSpiFlashProgrammer.pl script with the MCS file generated with the 32-bit (4-byte) SPI addressing option to make 'initial' and 'update' MCS files. When I program the 'initial' MCS (~88MB)  into the Flash memory the Kintex 7 fails to boot.

When I read back the Flash memory contents they match the MCS file used to program it so the flash programming seems to be working.   When I follow the same procedure with a simple design using a compressed bitfile that is only a few MB then the 'initial' MCS boots correctly and I can use the 'update' MCS written though the 'SpiFlashProgrammer.vhd' block to replace the original image and again boot the updated design correctly.

 

The main difference is that the larger design crosses the 128MB boundary which requires the FPGA to use 4-byte addressing mode.

I have looked at the boot header and the jump address to the upper copy of the MCS appears to be correct. It looks as it the FPGA configuration process is unable to handle data in the upper half of the Flash memory address space.

 

Has anyone else seen this problem?

 

More details :

:100FE000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF11
:100FF000 FFFFFFFFFFFFFFFFFFFFFFFFAA995566FF  ## line 257 Critical switch word in last location on the first page
:10100000 200000003002000100F4000030008001E8  ## Two lines of Quickboot header. 0x00F40000 is the address of the update region
:10101000 0000000F20000000200000002000000061
:10102000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0  ## Padding infront of 'golden' bitfile
:10103000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
..

.. golden bitfile..

..

..

:10FFF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF11
:02000004 00F4 06                             ## line 999669 Extended Linear Addr record (Type 04) Address is bits 31:16 of address
:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00   ## First page of update - padding, starting at 0x00F40000
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:10003000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0
:10004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
:10005000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB0
:10006000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA0
:10007000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90
:10008000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF80
:10009000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF70
:1000A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF60
:1000B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF50
:1000C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40
:1000D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF30
:1000E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF20
:1000F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF10
:10010000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
:10011000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEF
:10012000000000BB11220044FFFFFFFFFFFFFFFFA5 ## line 999688  Start of second (update) bit file
:10013000AA995566200000003003E0010000000C81
:100140003000800100000012200000003002200179

 

 

 

 

0 Kudos
14 Replies
Highlighted
Scholar
Scholar
11,972 Views
Registered: ‎06-05-2013

@gjones_cc Did you try this design bitstream with compression?

-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
Observer
Observer
5,960 Views
Registered: ‎03-23-2010

Hey gjones_cc,

 

I basically have the exact same problem. Could you solve it in the end?

 

Cheers,

Markus

0 Kudos
Highlighted
Visitor
Visitor
5,757 Views
Registered: ‎11-30-2016

I'm having similar issues.  I started with XAPP1081 and migrated the project to vivado 2016.2.  I have everything working if I limit my mcs imagesize to 64Mbit (128Mb minimum flash with 24 bit addressing).  I am aware that there are known 32 bit addressing issues with this Application note and example design.  My hope is that I can work through the issues anyway.  The quickboot method seems like a much simpler implementation than multiboot.   

 

My settings for MakeSpiFlashProgrammer.pl are:

xilPerl MakeSpiFlashProgrammerMcsFiles.pl -imagesize 100 mydesign.mcs

This requires a minimum flash size of 200Mb.  The output of the perl script displays a start address of X"00BF0000" and an end address of X"01680000".  This requires 32 bit addressing of the flash (MicronN25Q 256Mb for me).  If you look at the generated initial.mcs file, the wbstar (next_config_addr) field  address appears to be addressed as 24 bits (00BF0000).  If I attempt to load this file into flash as is, it does program and verify correctly, but the done pin never goes high and the FPGA doesn't boot.  If I manually change the wbstar field to 32 bit addressing (0000BF00) then the FPGA will boot from flash correctly.  

I'm trying to iron out the rest of the details of XAPP1081 for 32 bit addressing now.  The parameters from the perl script need to be entered in the SpiFlashProgrammer.vhd file.  I'm trying to determine if the cAddrUpdateStart and cAddrUpdateEnd constants need to be 24 bit or 32 bit addresses.  I have them set at 32 for now, but when I initialize the SpiFlashProgrammer, I successfully erase the switch word, but never see the regEraseOK status bit go high.  The state machine in SpiFlashProgrammer sends different commands to the flash depending on whether cAddrWidth is set to 32 or 24.  I'm wondering if there are issues with the state machine erase when cAddrWidth is set to 32.  I will provide an update if I sort this out.  

 

Any advice is appreciated.  Has anyone ever successfully modified XAPP1081 example files to work with 32 bit addressing?     

 

Thanks,

Rob

0 Kudos
Highlighted
Visitor
Visitor
5,754 Views
Registered: ‎11-30-2016

BTW, I am using bitstream compression.  I could most likely fit my quickboot design for the XC7K325T into a 128Mb flash, but the possibility exists to outgrow the allotted space, even with compression.  I am also working on a XC7K420 board.  This design will absolutely require 32 bit addressing.

 

Rob 

0 Kudos
Highlighted
Observer
Observer
4,312 Views
Registered: ‎02-03-2016

Hi Rob,

 

I'm having a similar issue with a 256Mb SPI on Artix-7.  Were you ever able to get the 32-bit addressing mode working?

 

Thanks,

Greg

 

0 Kudos
Highlighted
Scholar
Scholar
3,768 Views
Registered: ‎05-31-2012

Any updates?

Since i have an Artix7 xc7a200t the max bitstream size is 9730652 bytes if i'm not wrong. So could i use this design without worrying about the 32bit address limitation right?

I use the n25q256 flash

0 Kudos
Highlighted
Scholar
Scholar
3,733 Views
Registered: ‎05-31-2012

I tried the design and i have a different issue. I generated the bitstream with Vivado and with 32 bit addressing disabled, then i used prom gen to get the .mcs and finally the perl script. The FPGA boots.

Then i tried to import the original bitstream in SDK and add a bootloader to the internal ram and i created a download.bit file.

Same conversion as above, this time the FPGA won't boot!  The size of the bistream is increased by few KB (the bootloader is 32kB) from 2.4 MB to 2.6 MB so i shouldn't hit the 32 bit limitation.

Any thought?

0 Kudos
Highlighted
Visitor
Visitor
3,731 Views
Registered: ‎11-30-2016

All, I finally moved on and settled for 24 bit addressing which was sufficient for my needs with compression. I did get some help from Xilinx. They provided a new MakeSpiFlashProgrammerMCSFiles.pl that is 32 bit address width compatible. That's half of it. The other half is the SPIFlashProgrammer.vhd. If you're lucky, the file is compatible with your 256Mb or higher flash. In my case it wasn't. The incompatibility has to do with whether your flash supports 4-byte address mode commands, mine doesn't. I have part number: N25Q256A13EF840E which does not support enter and exit 4-byte address mode commands: cCmdREAD32 cCmdSE32 cCmdPP32 Rather the non-volatile register bit 0 needs to be set to 1 to enable 4-byte addressing. I believe the SPIFLASHPROGRAMMER module will need to be modified to support this flash type. I plan on coming back to this at some point, but I haven't had the chance yet. I'm happy to share the updated MakeSpiFlashProgrammerMCSFiles.pl file though. Best Regards, Rob
0 Kudos
Highlighted
Scholar
Scholar
3,726 Views
Registered: ‎05-31-2012

Hi Rob thanks for the update!

I tried today the design for the first time and found a strange different problem. If i program the bit file produced from Vivado is ok.

If i export the bit file to SDK and add a elf file to it  (so .bit + elf = download.bit) it doesn't work (the FPGA won't boot) The bootloader is inside FPGA memory (almost 32KB)

It's not much bigger (the bit size pass from 2.5MB to 2.7MB) so is far beyond from the 32bit limitation.

 

My goal is to not use the SPIFlashProgrammer.vhd  , i would like to use the AXI Quad spi core and program bitstream using it (loading bitstream by serial port). It means i don't even need mcs file, i could upload a raw bin file and add the required header (in theory, i haven't worked this out)

0 Kudos
Highlighted
Visitor
Visitor
2,800 Views
Registered: ‎11-30-2016

Interesting plan. Please let us know how it works out. Cheers, Rob
0 Kudos
Highlighted
Scholar
Scholar
2,712 Views
Registered: ‎05-31-2012

Thanks to Rob's new file i implemented the quickboot design successfully.

I simplified the script to have only the bitstream+biststream size + crc (not producing an mcs file). Then i upload this modified file through serial port to DDR.

I then implemented the algorithm described in the XAPP with a Microblaze C program and use the AXI quad spi core to update the SPI Flash.

Now i would like not to use perl to generate the image since is not present in Vivado, maybe i should convert to tcl.

 

 

0 Kudos
Highlighted
Visitor
Visitor
2,171 Views
Registered: ‎03-26-2018

Hi everyone! 

i'm doing xapp1081 as well. Did anyone has any progress? it seems i can't feed the programmer with the right update data contents. For me i converted *_update.mcs to .bin and tried to feed to inData32. is it ok?

looking forward to your reply, 

Nick

0 Kudos
Highlighted
Observer
Observer
263 Views
Registered: ‎10-07-2016

Hi,

     I have some problems in my application.   

1   The "spiFlashProgrammer.vhd " module works normally at " A7-100t + N25Q256A13 ".   

     The size of update_image.bin is  4MB, and the module works correctly,  FPGA will work correctly after reboot.

     constant cAddrWidth : integer := 24;

     cAddrUpdateStart : std_logic_vector(31 downto 0) := X"00400000";

     cAddrUpdateEnd : std_logic_vector(31 downto 0) := X"00800000";

     cIdcode24N25Q : std_logic_vector(23 downto 0) := X"20BA19";

2    The "spiFlashProgrammer.vhd " module dose not work at " K7-325T  + N25Q512A13 .  ".   

     The size of update_image.bin is  8MB, set as below :

     constant cAddrWidth : integer := 24;  or  constant cAddrWidth : integer := 32; 

     cAddrUpdateStart : std_logic_vector(31 downto 0) := X"00800000";

     cAddrUpdateEnd : std_logic_vector(31 downto 0) := X"01000000";

     cIdcode24N25Q : std_logic_vector(23 downto 0) := X"20BA20";

     when I send erase command to the module,  I find the FSM works differently to" A7-100t + N25Q256A13 "  ,as show below:

As to 256Mb , the chipscope got FF from inSSDData8Receive . 

As to 512Mb , the chipscope got 00 from inSSDData8Receive , so the next state is not right.

My question: 
1  Is this module support 512Mb flash ?  how to fix this problem?

2  Should I adjust cSizeSector to fix this issue?

7.png4.png5.png6.png

0 Kudos
Highlighted
Observer
Observer
242 Views
Registered: ‎10-07-2016

I use 512 Mb N25Q512 , Neither 24bit or 32bit addressing is work.
I can get regEraseOK = 1 very quickly, less than 1 seconds. Then send data to flash, the crc check will fail.
But its ok for 256Mb N25Q256, at 24bit addressing.
Cannt figure out the real reason.
0 Kudos