Getting consistent re-programming of PL from XSDK
724 views
Skip to first unread message
Rob Barris
Mar 5, 2018, 5:57:36 PM3/5/18
to snickerdoodle forum
Short description of the problem: it seems like I can only successfully push the button in XSDK to re-program the PL with a bitstream, one single time after power cycling the snickerdoodle. It will program successfully, but even if I turn around and immediately push the button again in XSDK, I get an "FPGA initialization failed" from XSDK and I cannot get the PL to program again until I power cycle the device once more. Also if I proceed to download app code and run it, pause it, kill it, at that point I can't re-program the PL either without that power cycle.
I am pretty sure this used to work fluidly, i.e. reliably enough that it could be scripted without any need for external power cycling etc.
My hobby machine setup:
Ubuntu 17.04 laptop
USB JTAG adapter (Digilent HS3)
Snickerdoodle Black on BreakyBreaky (rev3 breaky)
Vivado 2017.3
Baremetal operation (no SD card, no Linux boot)
It's only a mild irritant, as it takes way more time to compile a bitstream than it does to re-program the device, but it seems to me this used to work a lot better and I am wondering if there is some simple setting in XSDK that I could change up to re-establish the consistent "iron fist of reset".
Vivado 2017.3
Baremetal operation (no SD card, no Linux boot)
It's only a mild irritant, as it takes way more time to compile a bitstream than it does to re-program the device, but it seems to me this used to work a lot better and I am wondering if there is some simple setting in XSDK that I could change up to re-establish the consistent "iron fist of reset".
Markus
Mar 5, 2018, 6:54:26 PM3/5/18
to snickerdoodle forum
hello Rob Barris,
did you try set your run/debug configuration to reset PS, PL, program the FPGA and init PS?
weath...@krtkl.com
Mar 5, 2018, 6:57:35 PM3/5/18
to snickerdoodle forum
I have seen some past weirdness with resets in certain cases while running XSDK baremetal.
I specifically saw some instances where if the code running on the ARM was doing a lot of AXI memory accesses it would effectively "lock" the JTAG out.
Pure conjecture but I suspect this has something to do with how the AXI bus connecting the Coresight unit is structured/prioritized.
Try opening the XSCT console and do an 'rst -srst' on the target.
Also see if you are doing heavy AXI reads/writes that if you throttle your AXI reads/writes suddenly the JTAG accesses work reliably again.
-Jamil
I specifically saw some instances where if the code running on the ARM was doing a lot of AXI memory accesses it would effectively "lock" the JTAG out.
Pure conjecture but I suspect this has something to do with how the AXI bus connecting the Coresight unit is structured/prioritized.
Try opening the XSCT console and do an 'rst -srst' on the target.
Also see if you are doing heavy AXI reads/writes that if you throttle your AXI reads/writes suddenly the JTAG accesses work reliably again.
-Jamil
Rob Barris
Mar 5, 2018, 7:44:00 PM3/5/18
to snickerdoodle forum
Will definitely try these tips, appreciate the ideas. I do have to reinforce that I see this behavior even if I haven't launched an app yet. Like: power up, program PL once, let it sit for a spell, try to re-program the PL, can't do it.
Will report back later tonight during hobby hours
Will report back later tonight during hobby hours
weath...@krtkl.com
Mar 5, 2018, 8:45:56 PM3/5/18
to snickerdoodle forum
Rob,
What if you don't set XSDK to program the FPGA but rather have XSDK only load the .elf executable for the PS then switch back to Vivado and use the program hardware feature there to program the PL?
You should be able to have both open at the same time using the same JTAG. Pushing the bitstream to PL in XSDK is more of a convenience.
-Jamil
What if you don't set XSDK to program the FPGA but rather have XSDK only load the .elf executable for the PS then switch back to Vivado and use the program hardware feature there to program the PL?
You should be able to have both open at the same time using the same JTAG. Pushing the bitstream to PL in XSDK is more of a convenience.
-Jamil
Rob Barris
Mar 5, 2018, 11:39:26 PM3/5/18
to snickerdoodle forum
Simpler test in Vivado IDE hardware manager only.
Power up snickerdoodle, it shows up in the hardware manager view.
I program it once, no problem. However looking at the Tcl console I do see some suspicious messages about not being able to find a debug core?
Second programming attempt fails, very similar behavior to what I see in XSDK (bombs right at the beginning).
### here I hit refresh or something in the HW manager panel
refresh_hw_device [lindex [get_hw_devices xc7z020_1] 0]
### here I tried to program it again and it fails.
set_property PROBES.FILE {} [get_hw_devices xc7z020_1]
Power up snickerdoodle, it shows up in the hardware manager view.
I program it once, no problem. However looking at the Tcl console I do see some suspicious messages about not being able to find a debug core?
Second programming attempt fails, very similar behavior to what I see in XSDK (bombs right at the beginning).
open_hw_target
INFO: [Labtoolstcl 44-466] Opening hw_target localhost:3121/xilinx_tcf/Digilent/210299A562A9
set_property PROGRAM.FILE {/home/rbarris/sandbox/ray/ray2_ksdb/ray2_ksdb.runs/impl_1/system_wrapper.bit} [get_hw_devices xc7z020_1]
current_hw_device [get_hw_devices xc7z020_1]
refresh_hw_device -update_hw_probes false [lindex [get_hw_devices xc7z020_1] 0]
INFO: [Labtools 27-1435] Device xc7z020 (JTAG device index = 1) is not programmed (DONE status = 0).
set_property PROBES.FILE {} [get_hw_devices xc7z020_1]
set_property FULL_PROBES.FILE {} [get_hw_devices xc7z020_1]
set_property PROGRAM.FILE {/home/rbarris/sandbox/ray/ray2_ksdb/ray2_ksdb.runs/impl_1/system_wrapper.bit} [get_hw_devices xc7z020_1]
program_hw_devices [get_hw_devices xc7z020_1]
INFO: [Labtools 27-3164] End of startup status: HIGH
refresh_hw_device [lindex [get_hw_devices xc7z020_1] 0]
INFO: [Labtools 27-1434] Device xc7z020 (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).
### here I hit refresh or something in the HW manager panel
refresh_hw_device [lindex [get_hw_devices xc7z020_1] 0]
INFO: [Labtools 27-1434] Device xc7z020 (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).
### here I tried to program it again and it fails.
set_property PROBES.FILE {} [get_hw_devices xc7z020_1]
set_property FULL_PROBES.FILE {} [get_hw_devices xc7z020_1]
set_property PROGRAM.FILE {/home/rbarris/sandbox/ray/ray2_ksdb/ray2_ksdb.runs/impl_1/system_wrapper.bit} [get_hw_devices xc7z020_1]
program_hw_devices [get_hw_devices xc7z020_1]
INFO: [Labtools 27-3164] End of startup status: HIGH
refresh_hw_device [lindex [get_hw_devices xc7z020_1] 0]
INFO: [Labtools 27-1434] Device xc7z020 (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).
Rob Barris
Mar 6, 2018, 1:15:56 AM3/6/18
to snickerdoodle forum
Hi!
In answer to your question, when iterating on the software coding in XSDK, I explicitly don't want it to reset the PL and reload the FPGA logic on every app run / debug session, since it takes time. Presently if I don't have to change the bitstream, I can just recompile and re-run my app code without any need to reprogram the PL.
In answer to your question, when iterating on the software coding in XSDK, I explicitly don't want it to reset the PL and reload the FPGA logic on every app run / debug session, since it takes time. Presently if I don't have to change the bitstream, I can just recompile and re-run my app code without any need to reprogram the PL.
Rob Barris
Mar 6, 2018, 1:35:02 AM3/6/18
to snickerdoodle forum
What I am seeing, now with a freshly constructed dummy project (just the zynq7 PS and an AXI Timer in the block design), on a spare snickerdoodle-black and breaky board, no external hardware attached, is the same symptom in Vivado IDE hardware manager - I can program the FPGA after cold power up, but not a second time, using the "Program device" command at the top of the Vivado window.
Log spew from the Vivado Tcl console
Log spew from the Vivado Tcl console
set_property PROBES.FILE {} [get_hw_devices xc7z020_1]
set_property FULL_PROBES.FILE {} [get_hw_devices xc7z020_1]
set_property PROGRAM.FILE {/home/rbarris/zynqtest1/zynqtest1.runs/impl_1/design_1_wrapper.bit} [get_hw_devices xc7z020_1]
program_hw_devices [get_hw_devices xc7z020_1]
ERROR: [Labtools 27-3165] End of startup status: LOW
ERROR: [Common 17-39] 'program_hw_devices' failed due to earlier errors.
I also tried a few attempts in the XSCT console in XSDK to do the rst -srst but that went nowhere.
I'm on Vivado 2017.3, should I bother trying another version?
Should I break out the Saleae-pro16 and watch the JTAG bus during one of the failed attempts ?
Should I break out the Saleae-pro16 and watch the JTAG bus during one of the failed attempts ?
glen...@gmail.com
Jun 7, 2018, 5:38:21 AM6/7/18
to snickerdoodle forum
Rob,
Did you ever find a resolution to this issue? I'm bumping in to the same problem on my microZed board.
Rob Barris
Jun 7, 2018, 2:14:00 PM6/7/18
to snickerdoodle forum
Alas no. However I have not tried any more recent Vivado versions etc, in fact spent the last couple months working on a different part of my hobby project (all analog stuff). Which version are you using ?
glen...@gmail.com
Jun 7, 2018, 2:51:26 PM6/7/18
to snickerdoodle forum
2018.1
Reply all
Reply to author
Forward
0 new messages