UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor xavier0001
Visitor
8,934 Views
Registered: ‎11-04-2016

Unable to flash in 2016.3 SDK, worked in 2016.1

Hi everyone,

 

Recently our project has been upgraded from  2016.1 to 2016.3. The project builds as usual, but when it comes to flashing it to the board, it no longer works. Using "Xilinx Tools->Program Flash" gives the following message in the Console.

 

cmd /C program_flash -f C:\PROJECT_LOCATION\FOLDER\FOLDER\bootimage\BOOT.bin -offset 0 \
-flash_type qspi_single -blank_check -verify -cable type xilinx_tcf url TCP:127.0.0.1:3121 

****** Xilinx Program Flash
****** Program Flash v2016.3 (64-bit)
  **** SW Build 1682563 on Mon Oct 10 19:07:27 MDT 2016
    ** Copyright 1986-2016 Xilinx, Inc. All Rights Reserved.

Connecting to hw_server @ TCP:127.0.0.1:3121

Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-JTAG-HS2-210249992729
	Device 0: jsn-JTAG-HS2-210249992729-4ba00477-0

Retrieving Flash info...

Initialization done, programming the memory
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.
Problem in running uboot
Flash programming initialization failed.

ERROR: Flash Operation Failed

Is there something I'm missing?

 

Thanks in Advance.

 

0 Kudos
10 Replies
Xilinx Employee
Xilinx Employee
8,923 Views
Registered: ‎08-01-2008

Re: Unable to flash in 2016.3 SDK, worked in 2016.1

check these ARs it may help you
https://www.xilinx.com/support/answers/59174.html
https://www.xilinx.com/support/answers/59311.html
https://www.xilinx.com/support/answers/52538.html
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
Visitor sampat76
Visitor
8,898 Views
Registered: ‎07-31-2016

Re: Unable to flash in 2016.3 SDK, worked in 2016.1

What is the boot mode on your board? Try setting the boot mode to JTAG and try again.
0 Kudos
Highlighted
Visitor xavier0001
Visitor
8,856 Views
Registered: ‎11-04-2016

Re: Unable to flash in 2016.3 SDK, worked in 2016.1

Qspi. I'll try to get that done... meanwhile, is there a way to do it without having to change it to Jtag? Like some software option/flag to force the software to do what it has usually done before and ignore the uboot?

0 Kudos
Observer steveren
Observer
8,726 Views
Registered: ‎10-17-2013

Re: Unable to flash in 2016.3 SDK, worked in 2016.1

I have found much the same problem after upgrading from 2016.2. I haven't uninstalled the latter, and its program_flash command still works perfectly, but the new version just locks up.

The following is what happens when I use the older version:

$ ~/apps/Xilinx/SDK/2016.2/bin/program_flash -f image.bin \
  -flash_type qspi_single \
  -verify \
  -cable type xilinx_tcf url TCP:127.0.0.1:3121

****** Xilinx Program Flash
****** Program Flash v2016.2 (64-bit)
  **** SW Build 1577090 on Thu Jun  2 16:32:35 MDT 2016
    ** Copyright 1986-2016 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-JTAG-HS2-210249922947
        Device 0: jsn-JTAG-HS2-210249922947-4ba00477-0
        Device 1: jsn-JTAG-HS2-210249922947-13722093-0

Retrieving Flash info...

JTAG chain configuration
--------------------------------------------------
Device   ID Code        IR Length    Part Name
 1       4ba00477           4        arm_dap
 2       13722093           6        xc7z010

--------------------------------------------------
Enabling extended memory access checks for Zynq.
Writes to reserved memory are not permitted and reads return 0.
To disable this feature, run "debugconfig -memory_access_check disable".

--------------------------------------------------

CortexA9 Processor Configuration
-------------------------------------
Version.............................0x00000003
User ID.............................0x00000000
No of PC Breakpoints................6
No of Addr/Data Watchpoints.........4
Disabling PLL bypass.
Processor Reset .... DONE
SF: Detected N25Q256A with page size 256 Bytes, erase size 4 KiB, total 32 MiB

[...continues to erase, program and verify

But exactly the same command with 2016.3 is very different:

$ ~/apps/Xilinx/SDK/2016.3/bin/program_flash -f image.bin \
  -flash_type qspi_single \
  -verify \
  -cable type xilinx_tcf url TCP:127.0.0.1:3121

****** Xilinx Program Flash
****** Program Flash v2016.3 (64-bit)
  **** SW Build 1682563 on Mon Oct 10 19:07:26 MDT 2016
    ** Copyright 1986-2016 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-JTAG-HS2-210249922947
        Device 0: jsn-JTAG-HS2-210249922947-4ba00477-0

Retrieving Flash info...

Initialization done, programming the memory
BOOT_MODE REG = 0x00000011
WARNING: [Xicom 50-100] The current boot mode is QSPI.
If flash programming fails, configure device for JTAG boot mode and try again.
Disabling PLL bypass.

[...hangs...]

It doesn't actually seem to see both JTAG devices on the Zynq chip, which is probably the source of the problem since it's the second that is used for flash programming.

 

Given that your failure is in Windows and mine is in Linux, it looks like it's definitely a bug that's been introduced into flash_program rather than any external factor.

8,692 Views
Registered: ‎11-18-2016

Re: Unable to flash in 2016.3 SDK, worked in 2016.1

Hi Steveren,

I have exactly the same issue with SDK 2016.3 on Windows.
Did you find a way to solve this problem (except using 2016.2) ?

Thank you very much
Jonathan
0 Kudos
Observer steveren
Observer
8,553 Views
Registered: ‎10-17-2013

Re: Unable to flash in 2016.3 SDK, worked in 2016.1

No, sorry. I just use the older version.

Steve.
0 Kudos
Moderator
Moderator
8,451 Views
Registered: ‎10-06-2016

Re: Unable to flash in 2016.3 SDK, worked in 2016.1

Hi @steveren @jonathannarinx

 

I checked the utility in a ZC702 board and I was able to program the SPI in both JTAG and QSPI boot mode. Although the warning message recommends to use JTAG mode when programming the flash device, your issue is related to the MIO6 or PLL_BYPASS option.

 

When setting to '1' in the SW16 boot option switch the program_flash tool hangs in the 2016.3 release. Reviewing the message I would say that there is an issue when disabling the bypass in this release.

 

So check you boot configuration and set PLL_BYPASS (MIO6) to '0' when programming with 2016.3 release.

 

Regards

Ibai

 


Ibai
Don’t forget to reply, kudo, and accept as solution.
0 Kudos
Observer steveren
Observer
8,437 Views
Registered: ‎10-17-2013

Re: Unable to flash in 2016.3 SDK, worked in 2016.1

Ah, that's not the first bug related to PLL bypass. For years there has been a bug in the generation of init code (ps7_init.tcl, ps7_init.c, etc) that causes the boot to hang when PLL bypass is enabled. This, however, is easy to fix, since it's just a question of editing the generated source and can be automated.

 

I did post the workaround when I first discovered it, but maybe if I repeat it here, something might happen...

 

# fix the ps init bugs:
sed "s/mask_write 0XF800010\(.\) 0x00000010 0x00000010/mask_write 0XF800010\1 0x00000018 0x00000010/" \
  $SRC/ps7_init.tcl  | \
  sed "s/mask_write 0XE000A20\(.\) 0xFFFFFFFF 0x00000080/mask_write 0XE000A20\1 0xFFFFFFFF 0x00000081/" \
  >$DST/ps7_init_patched.tcl

# (note the misplaced comma in the C version original)
sed "s/EMIT_MASKWRITE(0XF800010\(.\), 0x00000010U ,0x00000010U),/EMIT_MASKWRITE(0XF800010\1, 0x00000018U ,0x00000010U),/" \
  $SRC/ps7_init.c  | \
  sed "s/EMIT_MASKWRITE(0XE000A20\(.\), 0xFFFFFFFFU ,0x00000080U/EMIT_MASKWRITE(0XE000A20\1, 0xFFFFFFFFU, 0x00000081U/" \
  >$DST/ps7_init_patched.c

This is specifically for Linux, but it should be clear enough what's happening.

 

Thanks for pinning the flash programming problem down, though.

 

Steve.

 

 

Moderator
Moderator
8,428 Views
Registered: ‎10-06-2016

Re: Unable to flash in 2016.3 SDK, worked in 2016.1

Hi @xavier0001

 

Did you able to program flash memory using JTAG boot mode? As you can see your issue does not seems to be related to the same issue, as your boot mode is QSPI flash without bypassing the PLL (BOOT_MODE = 0x00000001).

 

Regards,

Ibai


Ibai
Don’t forget to reply, kudo, and accept as solution.
0 Kudos
Observer steveren
Observer
3,226 Views
Registered: ‎10-17-2013

Re: Unable to flash in 2016.3 SDK, worked in 2016.1

And it would seem that this bug is still present in 2017.1 :-(((

0 Kudos