cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor
Visitor
6,858 Views
Registered: ‎11-24-2015

SDK 2017.3 qSPI flash programming fails

I recently upgraded to the 2017.3 release. I have a fully working design under the 2017.1 release. In this design, I am using a Micron  n25q512a and 2017.1 handles this part perfectly with no complaint. When I try to utilize Program Flash from the SDK menu with blank check box set, 2017.3 will always fail blank check. If I turn off blank check it reports successful program and verify, but does not really program the part.

 

If I revert to 2017.1 I am once again working. Again, there is no difference in my hardware or device files. 2017.1 works, 2017.3 does not with the only change being the substitution of the Xilinx SDK version.

 

 

37 Replies
Highlighted
Xilinx Employee
Xilinx Employee
6,843 Views
Registered: ‎09-22-2015

Re: SDK 2017.3 qSPI flash programming fails

Is this Zynq-7000 or Zynq UltraScale+ MPSoC? Please provide information based on the programming part of this checklist.

https://www.xilinx.com/support/answers/68656.html

 

------------------------------------------------------------------------------------------------------------------------
Please mark an answer "Accept as solution" if a post has the solution to your issue.
------------------------------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
6,822 Views
Registered: ‎11-24-2015

Re: SDK 2017.3 qSPI flash programming fails

This is an existing, previously working and production ready Zynq 7020 design.

 

My guess is that the statement:

 

The programming flow in 2017.2 and earlier is to set the boot mode pins to JTAG and issue a PS_POR_B before programming the QSPI. This tool limitation will be removed in 2017.3.

 

Our standard boot is qSPI mode and that setup has worked fine for the last couple of years. How do I restore default 2017.2 behavior to the tool to support existing designs ?

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
6,817 Views
Registered: ‎09-22-2015

Re: SDK 2017.3 qSPI flash programming fails

Well in that case, the above suggestions only apply to Zynq UltraScale+ MPSoC. 

------------------------------------------------------------------------------------------------------------------------
Please mark an answer "Accept as solution" if a post has the solution to your issue.
------------------------------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
6,805 Views
Registered: ‎10-30-2017

Re: SDK 2017.3 qSPI flash programming fails

I am having the same problem....

0 Kudos
Highlighted
Visitor
Visitor
6,804 Views
Registered: ‎10-30-2017

Re: SDK 2017.3 qSPI flash programming fails

Looks like they will not answer your question, what poor customer service. 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
6,760 Views
Registered: ‎10-21-2010

Re: SDK 2017.3 qSPI flash programming fails

@alex_panos@trimble_pome

We have run some tests in QSPI bootmode and haven't seen errors during blankcheck, and also, the image booted up. We're trying to find more details about what has changed and how it could effect the bootup

 

In the meantime, is it possible to send us a testcase to reproduce the errors

0 Kudos
Highlighted
Visitor
Visitor
6,749 Views
Registered: ‎12-03-2013

Re: SDK 2017.3 qSPI flash programming fails

I have the same problem since upgrading to 2017.3 with the Zedboard. The command I used prior to 2017.3 now fails:

> program_flash -f BOOT.bin -offset 0 -flash_type qspi_single -blank_check

****** Xilinx Program Flash
****** Program Flash v2017.3.1 (64-bit)
  **** SW Build 2018833 on Wed Oct  4 19:58:22 MDT 2017
    ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.

Connecting to hw_server @ TCP:localhost:3121

WARNING: Failed to connect to hw_server at TCP:localhost:3121
Attempting to launch hw_server at TCP:localhost:3121

Connected to hw_server @ TCP:localhost:3121
Available targets and devices:
Target 0 : jsn-Zed-210248571048
        Device 0: jsn-Zed-210248571048-4ba00477-0

ERROR: Please specify a valid FSBL file for flash type: qspi_single

 And if I create a ZYNQ FSBL with SDK 2017.3 (default options), I now get:

> program_flash -f BOOT.bin -fsbl bootloader.elf -offset 0 -flash_type qspi_single -blank_check

****** Xilinx Program Flash
****** Program Flash v2017.3.1 (64-bit)
  **** SW Build 2018833 on Wed Oct  4 19:58:22 MDT 2017
    ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.

Connecting to hw_server @ TCP:localhost:3121

WARNING: Failed to connect to hw_server at TCP:localhost:3121
Attempting to launch hw_server at TCP:localhost:3121

Connected to hw_server @ TCP:localhost:3121
Available targets and devices:
Target 0 : jsn-Zed-210248571048
        Device 0: jsn-Zed-210248571048-4ba00477-0

Retrieving Flash info...

Initialization done, programming the memory
BOOT_MODE REG = 0x00000000
f probe 0 0 0
Performing Erase Operation...
Erase Operation successful.
INFO: [Xicom 50-44] Elapsed time = 0 sec.
Performing Blank Check Operation...
0%...INFO: [Xicom 50-44] Elapsed time = 0 sec.
Blank Check Operation unsuccessful. The part is not blank.

ERROR: Flash Operation Failed

 

Do we need to activate a non-default setting in FSBL? Why was that option added for Zynq, it used to be only for Zynq Ultrascale+?

 

Thanks,

 

Jonathan

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
6,722 Views
Registered: ‎10-11-2011

Re: SDK 2017.3 qSPI flash programming fails

Please, when collecting the log from the Flash Programmer be sure to:

1. For debug purposes the Debug Environmental Variable XIL_CSE_ZYNQ_DISPLAY_UBOOT_MESSAGES can be set to 1. See (Xilinx Answer 59272) for more details.

2. Use an FSBL with FSBL_DEBUG_INFO defined and report the UART log.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
6,686 Views
Registered: ‎12-03-2013

Re: SDK 2017.3 qSPI flash programming fails

Here are the logs. Please don't hesitate if you require more information.

0 Kudos
Highlighted
Observer
Observer
5,182 Views
Registered: ‎11-17-2017

Re: SDK 2017.3 qSPI flash programming fails

I have the same issue:

 -with SDK 2017.3 the Flash-Program fails

- with SDK 2017.2 the Flash-Program works

 

The target is a Zedboard (Zynq 7000).

 

The console output of 2017.3 is:

cmd /C program_flash -f \
C:\Users\hhs1\Workspaces\Xilinx\ToolChainTest\ToolChainTest.sdk\BootImage\BOOT.mcs -offset \
0x00000000 -flash_type qspi_single -fsbl \
C:\Users\hhs1\Workspaces\Xilinx\ToolChainTest\ToolChainTest.sdk\FSBL\Debug\FSBL.elf \
-blank_check -verify -cable type xilinx_tcf url TCP:127.0.0.1:3121

****** Xilinx Program Flash
****** Program Flash v2017.3.1 (64-bit)
  **** SW Build 2035080 on Fri Oct 20 14:20:01 MDT 2017
    ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.

Connecting to hw_server @ TCP:127.0.0.1:3121

WARNING: Failed to connect to hw_server at TCP:127.0.0.1:3121
Attempting to launch hw_server at TCP:127.0.0.1:3121

Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-Zed-210248445790
    Device 0: jsn-Zed-210248445790-4ba00477-0

Retrieving Flash info...

Initialization done, programming the memory
BOOT_MODE REG = 0x00000000
f probe 0 0 0


Performing Erase Operation...
Erase Operation successful.
INFO: [Xicom 50-44] Elapsed time = 0 sec.
Performing Blank Check Operation...
0%...INFO: [Xicom 50-44] Elapsed time = 0 sec.
Blank Check Operation unsuccessful. The part is not blank.

ERROR: Flash Operation Failed

 

 

0 Kudos
Highlighted
Participant
Participant
5,045 Views
Registered: ‎01-26-2016

Re: SDK 2017.3 qSPI flash programming fails

For the sake of adding information to this problem diagnosis: I have a design that has always programmed fine with older tools, but when moving to 2017.3 (big jump from last-used 2015.x tools) it appears to succeed, but actually does not. This is with the boot mode set to QSPI on custom board with plain-and-simple boot from flash only hardware configuration. Since it's meant to load from flash and run all the time, which is perhaps obvious, there's no provision to change the boot mode to anything else (again, that's likely the most common use case for stand alone devices), and I'm just trying to reflash an existing complete unit. Flash file was built with 2017.3 bootgen (via SDK gui, in this case), and programs fine with 2015.4, but does not with 2017.3. No "blank check" is set. Flash is not erased or written, as the previously in-place configuration is what loads after the flash is complete and power is cycled.

0 Kudos
Highlighted
Participant
Participant
4,813 Views
Registered: ‎01-12-2018

Re: SDK 2017.3 qSPI flash programming fails

Hi all,

 

We have been struggling with this issue during this week and we have the same problem previously commented. We are not able to verify after flash and Blank check after erase using XSDK 2017.3 but XSDK 2017.1 works perfect.

 

My question is can we flash a BOOT.bin that has embedded a created 2017.01 U-Boot with XSDK 2017.3 or it needs to be 2017.3 U-Boot?

 

Thank you very much,

 

Jorge

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
4,793 Views
Registered: ‎09-22-2015

Re: SDK 2017.3 qSPI flash programming fails

Please provide information based on the programming part of this checklist.

https://www.xilinx.com/support/answers/68656.html

 

Please make sure you have the FSBL_DEBUG_DETAILED flag enabled as mentioned in the Answer Record.

------------------------------------------------------------------------------------------------------------------------
Please mark an answer "Accept as solution" if a post has the solution to your issue.
------------------------------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Observer
Observer
4,706 Views
Registered: ‎09-12-2017

Re: SDK 2017.3 qSPI flash programming fails

is this problem sovled ,i have the same problem. sometimes .it works and i can program flash,at most time it not work well. why ?

 

can you support us ? 

0 Kudos
Highlighted
Moderator
Moderator
4,534 Views
Registered: ‎03-19-2014

Re: SDK 2017.3 qSPI flash programming fails

Try adding this environment variable

 

XIL_CSE_ZYNQ_UBOOT_QSPI_FREQ_HZ = 10000000

 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Highlighted
Participant
Participant
4,528 Views
Registered: ‎01-26-2016

Re: SDK 2017.3 qSPI flash programming fails


@akshayva wrote:

Please provide information based on the programming part of this checklist.

https://www.xilinx.com/support/answers/68656.html

Please make sure you have the FSBL_DEBUG_DETAILED flag enabled as mentioned in the Answer Record.


That section (section 4) is about booting, not about programming the flash. As previously stated (at least in my post), the Zynq still boots from the flash fine, but the tools do not program the flash at all. If one programs the flash with 2017.2, the zynq boots from it and runs. If instead one programs the flash from 2017.3, the image doesn't get written and the zynq boots the image that was already in the flash, not the new image that was supposedly just written to flash. As such, the compiled binary and flash image are fine, it's just not getting written to flash when using 2017.3. In fact flash isn't even erased with 2017.3, since the original image remains and still boots after attempting to program flash with 2017.3. Section 5 appears to be relevant, but the Answer Records linked are specific to MPSoC, while this problem is happening with plain old zynq-7000. AR# 68237 specifically states that it doesn't apply to 2017.3, so it's not the cause of this problem since it's known to happen with 2017.3. AR# 66715 states that it's specific to Ultrascale+ MPSoC, and is fixed in 2017.3, so it too, is not relevant. Might I suggest that someone at Xilinx simply create a bitstream for your favorite dev board with 2017.2, program it to flash via SDK, and see that it works. Then either change the bitstream and regenerate it or erase the flash, and then attempt to program it with 2017.3 SDK and see that programming fails. Should take a grand total of about 20 minutes. Please correct me if I'm wrong, but adding #defines to the source code isn't going to change how the flash is programmed.
0 Kudos
Highlighted
Participant
Participant
4,526 Views
Registered: ‎01-26-2016

Re: SDK 2017.3 qSPI flash programming fails


@glena wrote:

Try adding this environment variable

 

XIL_CSE_ZYNQ_UBOOT_QSPI_FREQ_HZ = 10000000

 

 


Do you mean to say that the SDK will pick up this environment variable and change the frequency at which the QSPI flash is programmed?
0 Kudos
Highlighted
Moderator
Moderator
4,522 Views
Registered: ‎03-19-2014

Re: SDK 2017.3 qSPI flash programming fails

Yes, this environment variable will change the QSPI clocking in mini-uBoot, which is used to program the QSPI.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Highlighted
Participant
Participant
4,518 Views
Registered: ‎01-26-2016

Re: SDK 2017.3 qSPI flash programming fails


@glena wrote:

Yes, this environment variable will change the QSPI clocking in mini-uBoot, which is used to program the QSPI.


I see a related thread here: https://forums.xilinx.com/t5/Embedded-Boot-and-Configuration/Can-t-erase-flash-on-Zynq-Vivado-SDK-2017-3/m-p/832958#M267 I will do this and report back.
0 Kudos
Highlighted
Observer
Observer
4,521 Views
Registered: ‎07-07-2016

Re: SDK 2017.3 qSPI flash programming fails

I work on custom board with Zynq-7010.
And I have the same trouble in 2017.4

 

I try flash N25Q256 in 2017.4, but all what i see it is progress bar of "programming" and execution fsbl.elf (via UART terminal), but after resetting board I doesn't see new fsbl (I see previous firmware). Also, I try programming flash with set Verify check, and SDK fail with it.


I try all it in 2016.3 and it perfectly work! My QSPI flash is "programmed" and I see my new fsbl (new date and etc). 

 

Here log of SDK

 

With regards,

Gustov Vladimir

0 Kudos
Highlighted
Participant
Participant
4,459 Views
Registered: ‎01-26-2016

Re: SDK 2017.3 qSPI flash programming fails


@stevecurrie wrote:

@glena wrote:

Yes, this environment variable will change the QSPI clocking in mini-uBoot, which is used to program the QSPI.


I see a related thread here: https://forums.xilinx.com/t5/Embedded-Boot-and-Configuration/Can-t-erase-flash-on-Zynq-Vivado-SDK-2017-3/m-p/832958#M267 I will do this and report back.

@glena, I set the environment variable in Win7, rebooted, confirmed the existence of the env variable in the XSDK command line console, launched XSDK 2017.3 and attempted to program flash... it failed as before: appears to succeed, but nothing is actually in flash.

 

UPDATE: I switched to a dev board with a much smaller flash image to save time testing this, and with 2017.4 and setting the environment variable as instructed, I was able to program the QSPI flash with the boot mode set to QSPI. That seems like an "it works" to me. I'll dig into the hardware I was using first at another time, but the quick dev board test indicates success, it seems. Thanks, @glena.

0 Kudos
Highlighted
Moderator
Moderator
4,455 Views
Registered: ‎03-19-2014

Re: SDK 2017.3 qSPI flash programming fails

please post the log file.  Make sure the environment variable XIL_CSE_ZYNQ_DISPLAY_UBOOT_MESSAGES is set to 1, this will provide enhanced log information of the program_flash operation

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
4,425 Views
Registered: ‎10-11-2011

Re: SDK 2017.3 qSPI flash programming fails

Can you try to set this environmental variable to your machine.

XIL_CSE_ZYNQ_UBOOT_QSPI_FREQ_HZ = 10000000 and try the programming once again?

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Participant
Participant
4,324 Views
Registered: ‎01-26-2016

Re: SDK 2017.3 qSPI flash programming fails


@glenawrote:

please post the log file.  Make sure the environment variable XIL_CSE_ZYNQ_DISPLAY_UBOOT_MESSAGES is set to 1, this will provide enhanced log information of the program_flash operation


I apologize for seeming to flip-flop on this, but I finally returned to testing this on the custom hardware I first used (instead of a development board) and 2017.3, with both env variables mentioned so far set accordingly, failed to program the flash, but 2015.4 worked as it always has. The log didn't go to a file, per se, so here's snippets from the 2017.3 programming console output (bulk repetitions reduced):

 

cmd /C program_flash -f \
C:\path\board.mcs -offset \
0 -flash_type qspi_single -fsbl \
C:\path\fsbl.elf \
-cable type xilinx_tcf url TCP:127.0.0.1:3121

****** Xilinx Program Flash
****** Program Flash v2017.3 (64-bit)
  **** SW Build 2018833 on Wed Oct  4 19:58:22 MDT 2017
    ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.

Connecting to hw_server @ TCP:127.0.0.1:3121

WARNING: Failed to connect to hw_server at TCP:127.0.0.1:3121
Attempting to launch hw_server at TCP:127.0.0.1:3121

Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-DLC10-0000177f3fa301
    Device 0: jsn-DLC10-0000177f3fa301-4ba00477-0

Retrieving Flash info...

Initialization done, programming the memory
===== mrd->addr=0xF800025C, data=0x00000001 =====
BOOT_MODE REG = 0x00000001
WARNING: [Xicom 50-100] The current boot mode is QSPI.
If flash programming fails, configure device for JTAG boot mode and try again.
===== mrd->addr=0xF8007080, data=0x30800100 =====
===== mrd->addr=0xF8000B18, data=0x00008000 =====
===== mrd->addr=0xF8000008, data=0x00000000 =====
===== mwr->addr=0xF8000008, data=0x0000DF0D =====
MASKWRITE: addr=0xF8000008, mask=0x0000FFFF, newData=0x0000DF0D
===== mrd->addr=0xF8000110, data=0x00177EA0 =====
===== mwr->addr=0xF8000110, data=0x00177EA0 =====
MASKWRITE: addr=0xF8000110, mask=0x003FFFF0, newData=0x00177EA0
===== mrd->addr=0xF8000100, data=0x0001A008 =====
===== mwr->addr=0xF8000100, data=0x0001A008 =====
MASKWRITE: addr=0xF8000100, mask=0x0007F000, newData=0x0001A008
===== mrd->addr=0xF8000100, data=0x0001A008 =====
===== mwr->addr=0xF8000100, data=0x0001A010 =====
MASKWRITE: addr=0xF8000100, mask=0x00000018, newData=0x0001A010
===== mrd->addr=0xF8000100, data=0x0001A010 =====
===== mwr->addr=0xF8000100, data=0x0001A011 =====
MASKWRITE: addr=0xF8000100, mask=0x00000001, newData=0x0001A011
===== mrd->addr=0xF8000100, data=0x0001A011 =====
===== mwr->addr=0xF8000100, data=0x0001A010 =====
MASKWRITE: addr=0xF8000100, mask=0x00000001, newData=0x0001A010
===== mrd->addr=0xF800010C, data=0x0000003F =====
READ: addr=0xF800010C, Data=0x0000003F
===== mrd->addr=0xF8000100, data=0x0001A010 =====
===== mwr->addr=0xF8000100, data=0x0001A000 =====
MASKWRITE: addr=0xF8000100, mask=0x00000010, newData=0x0001A000
===== mrd->addr=0xF8000120, data=0x1F000400 =====
===== mwr->addr=0xF8000120, data=0x1F000400 =====
MASKWRITE: addr=0xF8000120, mask=0x1F003F30, newData=0x1F000400
===== mrd->addr=0xF8000118, data=0x00177EA0 =====
===== mwr->addr=0xF8000118, data=0x00177EA0 =====
MASKWRITE: addr=0xF8000118, mask=0x003FFFF0, newData=0x00177EA0
===== mrd->addr=0xF8000108, data=0x0001A008 =====
===== mwr->addr=0xF8000108, data=0x0001A008 =====
MASKWRITE: addr=0xF8000108, mask=0x0007F000, newData=0x0001A008
===== mrd->addr=0xF8000108, data=0x0001A008 =====
===== mwr->addr=0xF8000108, data=0x0001A010 =====
MASKWRITE: addr=0xF8000108, mask=0x00000018, newData=0x0001A010
===== mrd->addr=0xF8000108, data=0x0001A010 =====
===== mwr->addr=0xF8000108, data=0x0001A011 =====
MASKWRITE: addr=0xF8000108, mask=0x00000001, newData=0x0001A011
===== mrd->addr=0xF8000108, data=0x0001A011 =====
===== mwr->addr=0xF8000108, data=0x0001A010 =====
MASKWRITE: addr=0xF8000108, mask=0x00000001, newData=0x0001A010
===== mrd->addr=0xF800010C, data=0x0000003F =====
READ: addr=0xF800010C, Data=0x0000003F
===== mrd->addr=0xF8000108, data=0x0001A010 =====
===== mwr->addr=0xF8000108, data=0x0001A000 =====
MASKWRITE: addr=0xF8000108, mask=0x00000010, newData=0x0001A000
===== mrd->addr=0xF8000004, data=0x00000000 =====
===== mwr->addr=0xF8000004, data=0x0000767B =====
MASKWRITE: addr=0xF8000004, mask=0x0000FFFF, newData=0x0000767B
Info:  Remapping 256KB of on-chip-memory RAM memory to 0xFFFC0000.
===== mrd->addr=0xF8000008, data=0x00000000 =====
===== mwr->addr=0xF8000008, data=0x0000DF0D =====
MASKWRITE: addr=0xF8000008, mask=0x0000FFFF, newData=0x0000DF0D
===== mwr->addr=0xF8000910, data=0x000001FF =====
===== mrd->addr=0xF8000004, data=0x00000000 =====
===== mwr->addr=0xF8000004, data=0x0000767B =====
MASKWRITE: addr=0xF8000004, mask=0x0000FFFF, newData=0x0000767B


U-Boot 2017.01-00148-g4c61f9b-dirty (Sep 22 2017 - 09:50:06 -0600), Build: jenkins-mini_uboot-mini_uboot-218

Model: Zynq CSE QSPI Board
Board: Xilinx Zynq
DRAM:  ECC disabled 256 KiB

WARNING: Caches not enabled
Using default environment

In:    dcc
Out:   dcc
Err:   dcc

Model: Zynq CSE QSPI Board
Board: Xilinx Zynq
Zynq> sf probe 0 10000000 0

SF: unrecognized JEDEC id bytes: 00, 00, 00
Failed to initialize SPI flash at 0:0 (error -2)

Zynq> Sector size = 0.
f probe 0 10000000 0

Performing Erase Operation...
sf erase 0 9E0000

No SPI flash selected. Please run `sf probe'

Zynq> Erase Operation successful.
INFO: [Xicom 50-44] Elapsed time = 1 sec.
Performing Program Operation...
0%...sf write FFFC0000 0 20000


No SPI flash selected. Please run `sf probe'
Zynq> sf write FFFC0000 20000 20000
[...snip...]
No SPI flash selected. Please run `sf probe'
Zynq> 50%...sf write FFFC0000 4E0000 20000
[...snip...]
No SPI flash selected. Please run `sf probe'
Zynq> 100%
sf write FFFC0000 9C0000 15250
No SPI flash selected. Please run `sf probe'

Zynq> Program Operation successful.
INFO: [Xicom 50-44] Elapsed time = 184 sec.

Flash Operation Successful
0 Kudos
Highlighted
Visitor
Visitor
4,148 Views
Registered: ‎03-08-2018

Re: SDK 2017.3 qSPI flash programming fails

I am not having any success with 2017.4 program_flash too.  We are using the MX6651235FZ2I-10G QSPI flash part, it is one of the Xilinx "known to be good" devices.   One of our laptops has 2016.4, it works fine.  I'm using 2017.4, it fails.  I am seeing the following messages during program:

 

Xilinx First Stage Boot Loader
Release 2017.4 Apr 9 2018-16:03:12
Devcfg driver initialized
Silicon Version 3.1
Boot mode is QSPI
Single Flash Information
FlashID=0xC2 0x20 0x1A
MACRONIX 512M Bits
QSPI is in single flash connection
QSPI is in 4-bit mode
QSPI Init Done
Flash Base Address: 0xFC000000
Reboot status register: 0x60502000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x8888C8CC
Bank Selection 136
BankSel 136 != Register Read 0
Bank Selection Failed
Move Image failed
Header Information Load Failed
Partition Header Load Failed
�SBL Status = 0xA00E

 

 

Any clues?  I don't want to go back to 2016.4 because it had other issues that were resolved in 2017.4.  

0 Kudos
Highlighted
Participant
Participant
4,140 Views
Registered: ‎01-26-2016

Re: SDK 2017.3 qSPI flash programming fails

Currently, I think the best course of action is to use whichever version of tools you want for all of development, but when it comes to programming flash, use something prior to the broken versions of 2017.x. If you examine the detailed log I posted above, you'll see there's a point where the actual flash writing entity (which appears to be uboot running on the Zynq) fails to recognize the flash. I suspect that's where things go wrong. If you set the two environment variables described in this thread and attempt your programming, you'll get the detailed output, which you can post here to further the diagnostic effort.

0 Kudos
Highlighted
Observer
Observer
3,987 Views
Registered: ‎03-12-2013

Re: SDK 2017.3 qSPI flash programming fails

I have the same problem. Did you solve it ?

0 Kudos
Highlighted
Participant
Participant
3,981 Views
Registered: ‎01-26-2016

Re: SDK 2017.3 qSPI flash programming fails

It doesn't appear to be 'fixed' yet (haven't tried latest tools), but the workaround I suggested is still valid.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
3,971 Views
Registered: ‎10-11-2011

Re: SDK 2017.3 qSPI flash programming fails

The post from patholden  seems to be a different kind of issue. Maybe best to move it to a separate thread.

Multiboot Register: 0x0000C000 shows the image has been found at a non-zero offset.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos