News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

ZynqBerry mass programming

Started by NZ, June 18, 2018, 04:51:16 PM

Previous topic - Next topic

NZ

Hallo all! The project I am currently working on for the Zynqberry is finally ready to go into production and I have now hit a bit of a wall when it comes to mass-programming Berries. So far I have programmed it using Xilinx's SDK. Now that's a beast of a program that uses tens of gigabytes for something which should be a fairly straight forward and easy task. It also means I dare not hand this over to our production guys as the SDK requires the whole project and whatever. I basically only want to hand them a small flash program, the BOOT.BIN file and the special zynq-fsbl for flashing.

I am currently struggling with Vivado Lab, which is at least a heck of a lot smaller to install (still several hundred megs!) but I can't get it to properly recognize the QSPI chip (S25FL127SABMFV10). When I add the memory configuration part I think I should choose the s25fl128s-3.3v-qspi-x4-single, as far as I can tell it's the 3.3V version and the wiki says all four lanes are connected. But it just instantly fails the moment I click 'Program' without any decent explanation is to why. Because I am stubborn I also tried other versions but they all instantly fail.

So. Long story short: is there a decent program that allows my production guys to mass program ZynqBerries with a minimal amount of effort?

If no: does anybody know of a way to achieve this goal?

JH

Hello,
on Vivado you must select "s25fl128s-3.3v-qspi-x4-single" on  SDK "qspi_single"

With Vivado/SDK 2017.3 and newer you must also select FSBL on Vivado GUI. You must use special FSBL for Flash programming, we have provide on our 2017.4 reference design, because Flash programming faild with default FSBL. You can use prebuilt version for this case test_board\prebuilt\software\<assembly version>\zynq_fsbl_flash.elf.
Download:
Documentation:You can automate to us console tools, which are included into SDK:Path of the programm: C:\Xilinx\SDK\2017.4\bin>open help:  .\program_flash -helpprogram ZynqBerry: program_flash -f <path>/Boot.bin -fsbl <path>/zynq_fsbl_flash.elf -flash_type qspi_single

We can also offer to program flash with your files. But minimum order must be 100 pieces. If you are interested to write to support@trenz-electronic.de for more details .
brJohn



NZ

Ah, so I did choose the right chip type. Doesn't matter though, Vivado Lab keeps refusing to do the work. I installed the full Xilinx SDK as well on my Windows machine but it too refuses to properly handle the JTAG (driver is installed). Maybe it's just Windows 10. The SDK works just fine on my Ubuntu VM.

I found the program_flash binary and the command line works like a charm. For now I think I'll just grab an old laptop and install Ubuntu on it for our production guys to use.

In my next team meeting I'll be sure to mention the possibility about having Trenz do the programming work for us! Surely it must be cheaper to do it 100 at a time by Trenz then one by one by someone here.  ;)

JH

Hi,
normally JTAG works fine on WinOS ... I use win ;-)

Can you explain trouble with JTAG on WinOS? Maybe I can help.

VM and JTAG is not a good choice. We've had bad experiences with this combination.

br
John

NZ

Okay, I wanted to include a copy of the error messages to be thorough and now the whole Vivado Lab thing just works on Windows 10. I don't know what changed other than that I turned my computer off at the end of the work day. So... maybe a reboot was required after installing Lab?  ??? And the whole programming/verifying is literally done in a mere fraction of the time it takes in my Ubuntu VM (3.5 minutes instead of 40). Uhm, yeah, weird.

Just to be thorough (and to leave something for my fellow internet denizens) these are the steps I take in Vivado Lab. They are based on post #9 from this link: https://forums.xilinx.com/t5/Configuration/Zynq-QSPI-Flash-How-can-I-program-stand-alone-w-o-SDK/td-p/683917

1) After starting Lab I click on "Open Hardware Manager"
2) At the top of the window there's a green bar that says "No hardware target is open. Open target".
3) Click on Open target, choose "Auto Connect" from the drop-down menu.
4) Wait a little. And then in the Tcl Console the following output appears:

start_gui
open_hw
connect_hw_server
INFO: [Labtools 27-2285] Connecting to hw_server url TCP:localhost:3121
INFO: [Labtools 27-2222] Launching hw_server...
INFO: [Labtools 27-2221] Launch Output:

****** Xilinx hw_server v2018.1
  **** Build date : Apr  4 2018-19:32:53
    ** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.


connect_hw_server: Time (s): cpu = 00:00:01 ; elapsed = 00:00:07 . Memory (MB): peak = 676.289 ; gain = 0.000
open_hw_target
INFO: [Labtoolstcl 44-466] Opening hw_target localhost:3121/xilinx_tcf/Digilent/25163300059DA
open_hw_target: Time (s): cpu = 00:00:03 ; elapsed = 00:00:09 . Memory (MB): peak = 1278.445 ; gain = 602.156
current_hw_device [get_hw_devices xc7z010_1]
refresh_hw_device -update_hw_probes false [lindex [get_hw_devices xc7z010_1] 0]
INFO: [Labtools 27-1434] Device xc7z010 (JTAG device index = 1) is programmed with a design that has no supported debug core(s) in it.
WARNING: [Labtools 27-3361] The debug hub core was not detected.
Resolution:
1. Make sure the clock connected to the debug hub (dbg_hub) core is a free running clock and is active.
2. Make sure the BSCAN_SWITCH_USER_MASK device property in Vivado Hardware Manager reflects the user scan chain setting in the design and refresh the device.  To determine the user scan chain setting in the design, open the implemented design and use 'get_property C_USER_SCAN_CHAIN [get_debug_cores dbg_hub]'.
For more details on setting the scan chain property, consult the Vivado Debug and Programming User Guide (UG908).


5) I go to the Hardware overview and open the context menu of xc7z010_1 (1). Then I choose "Add Configuration Memory Device".
6) Filter the list for the s25fl128s-3.3v-qspi-x4-single, select it and press OK.
7) Lab now asks me if I want to program the device. Yes I do.
8.) For the configuration file field I point it to a BOOT.BIN I prepared earlier.
9) For the Zynq FSBL I point it to the special flash elf from the Trenz wiki.
10) Ensure that Erase, Program and Verify are enabled.
11) Hit okay and wait for it to finish. Here's the output:

program_hw_cfgmem -hw_cfgmem [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
WARNING: [Xicom 50-100] The current boot mode is QSPI.
If flash programming fails, configure device for JTAG boot mode and try again.
f probe 0 0 0
Performing Erase Operation...
Erase Operation successful.
INFO: [Xicom 50-44] Elapsed time = 34 sec.
Performing Program Operation...
Program Operation successful.
INFO: [Xicom 50-44] Elapsed time = 71 sec.
Performing Verify Operation...
INFO: [Xicom 50-44] Elapsed time = 86 sec.
Verify Operation successful.
INFO: [Labtoolstcl 44-377] Flash programming completed successfully
program_hw_cfgmem: Time (s): cpu = 00:00:01 ; elapsed = 00:03:15 . Memory (MB): peak = 1354.273 ; gain = 0.617
endgroup
ERROR: [Labtoolstcl 44-513] HW Target shutdown. Closing target: localhost:3121/xilinx_tcf/Digilent/25163300059DA
ERROR: [Labtoolstcl 44-513] HW Target shutdown. Closing target: localhost:3121/xilinx_tcf/Digilent/25163300059DA
disconnect_hw_server localhost:3121
connect_hw_server
INFO: [Labtools 27-2285] Connecting to hw_server url TCP:localhost:3121
open_hw_target
INFO: [Labtoolstcl 44-466] Opening hw_target localhost:3121/xilinx_tcf/Digilent/251633000DC1A
current_hw_device [get_hw_devices xc7z010_1]
refresh_hw_device -update_hw_probes false [lindex [get_hw_devices xc7z010_1] 0]
INFO: [Labtools 27-1434] Device xc7z010 (JTAG device index = 1) is programmed with a design that has no supported debug core(s) in it.
WARNING: [Labtools 27-3361] The debug hub core was not detected.
Resolution:
1. Make sure the clock connected to the debug hub (dbg_hub) core is a free running clock and is active.
2. Make sure the BSCAN_SWITCH_USER_MASK device property in Vivado Hardware Manager reflects the user scan chain setting in the design and refresh the device.  To determine the user scan chain setting in the design, open the implemented design and use 'get_property C_USER_SCAN_CHAIN [get_debug_cores dbg_hub]'.
For more details on setting the scan chain property, consult the Vivado Debug and Programming User Guide (UG908).
create_hw_cfgmem -hw_device [lindex [get_hw_devices xc7z010_1] 0] [lindex [get_cfgmem_parts {s25fl128s-3.3v-qspi-x4-single}] 0]
set_property PROGRAM.BLANK_CHECK  0 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
set_property PROGRAM.ERASE  1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
set_property PROGRAM.CFG_PROGRAM  1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
set_property PROGRAM.VERIFY  1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
set_property PROGRAM.CHECKSUM  0 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
refresh_hw_device [lindex [get_hw_devices xc7z010_1] 0]
INFO: [Labtools 27-1434] Device xc7z010 (JTAG device index = 1) is programmed with a design that has no supported debug core(s) in it.
WARNING: [Labtools 27-3361] The debug hub core was not detected.
Resolution:
1. Make sure the clock connected to the debug hub (dbg_hub) core is a free running clock and is active.
2. Make sure the BSCAN_SWITCH_USER_MASK device property in Vivado Hardware Manager reflects the user scan chain setting in the design and refresh the device.  To determine the user scan chain setting in the design, open the implemented design and use 'get_property C_USER_SCAN_CHAIN [get_debug_cores dbg_hub]'.
For more details on setting the scan chain property, consult the Vivado Debug and Programming User Guide (UG908).
set_property PROGRAM.ADDRESS_RANGE  {use_file} [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
set_property PROGRAM.FILES [list "C:/Dev/ZynqBerry/Finalized_Images/20180620/ALL_IN_ONE.BIN" ] [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
set_property PROGRAM.BIN_OFFSET {0} [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
set_property PROGRAM.ZYNQ_FSBL {C:/Dev/ZynqBerry/Finalized_Images/20180620/zynq_fsbl_flash.elf} [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
set_property PROGRAM.BLANK_CHECK  0 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
set_property PROGRAM.ERASE  1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
set_property PROGRAM.CFG_PROGRAM  1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
set_property PROGRAM.VERIFY  1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
set_property PROGRAM.CHECKSUM  0 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
startgroup
program_hw_cfgmem -hw_cfgmem [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z010_1] 0]]
WARNING: [Xicom 50-100] The current boot mode is QSPI.
If flash programming fails, configure device for JTAG boot mode and try again.
f probe 0 0 0
Performing Erase Operation...
Erase Operation successful.
INFO: [Xicom 50-44] Elapsed time = 34 sec.
Performing Program Operation...
Program Operation successful.
INFO: [Xicom 50-44] Elapsed time = 72 sec.
Performing Verify Operation...
INFO: [Xicom 50-44] Elapsed time = 87 sec.
Verify Operation successful.
INFO: [Labtoolstcl 44-377] Flash programming completed successfully
program_hw_cfgmem: Time (s): cpu = 00:00:01 ; elapsed = 00:03:16 . Memory (MB): peak = 1365.109 ; gain = 0.000
endgroup


When it failed it failed straight after the program_hw_cfgmem TCL command had been given. I should've copied the error message yesterday.  :(

Anyhow, I hope somebody else can make use of these steps.

JH

Hi,

step 4 log is Ok, if the FPGA is not programmed or the design does not include a debug core. HW Manager did not know, what's included, so it send a warning (the most warnings can be ignored, only not, if you think this should not happens --> for example you has include a debug core).
step 11 log is OK, like you said. Maybe you has used default FSBL instead of special FSBL for Flash on GUI yesterday or connect more than one device (sometimes this can make trouble).

If you can reproduce this error again, send me the log and I will check. Maybe I can help.

br
John