12-21-2016 10:30 AM
I just upgraded to Vivado 16.4 yesterday. I'm not sure if this is an SDK bug (or possibly Vivado bug) or just coincident (and I already removed 16.3). I went to Run (Launch on hardware with GDB) and came up with the "No Elf file associated with target". I launched from the Project explorer elf file line, so it clearly exists. I don't know where to look for the association. I've looked in properties and in run configurations. The message is coming from init.tcl. The hardware is custom, based on Z010 using JTAG-HS3. The program is bare metal and was running yesterday. Part of my problem is that I'm still learning the inner workings of a very complex system. I don't know what menu to look for for this piece of information, let alone what file(s) it passes through to be used.
I haven't found any other messages about this, which makes me think it may be new to 16.4
12-21-2016 10:50 AM
Also a related question. I recently read where running and debugging on GDB was depreciated in favor of System Debugger. But I have not been able to launch on system debugger. I'm not sure if it is because SDK doesn't create an appropriate configuration automatically, or if it just isn't appropriate for a bare metal Zynq target. It always tried to launch a Linux debugging session, which was not appropriate and therefore failed.
As part of trying to work around the problem in the previous post, I tried to create a System Debugger configuration, but when I ran it, SDK exited after reporting a stack overflow. That presumably is an SDK bug, as I don't know how a user should be capable of creating a configuration that should result in a stack overflow. (Again not sure if this is new to 2016.4, as I hadn't tried this on a previous version).
12-21-2016 02:45 PM
Additional information. When the .hdf file from Vivado (16.4) is loaded into SDK 16.3 it results in the same problem. So I think SDK is off the hook. It is either a problem with Vivado 16.4 or something wrong in the Vivado project, both of which surprise me, because I don't know what vivado has to do with how the SDK debugger handles initialization. There are differences in the p7_init.tcl file generated by the new .hdf file, but they have all been carefully examined and are benign and not related to the elf file. Whatever mis-information is coming in from the .hdf file is impacting some other aspect of SDK.
12-22-2016 03:31 PM
This is at least a work around, although it raises some questions. I created a RUN profile using System Debugger and it launched properly.
1. The documentation recommends using System Debugger and depreciates GDB.
2. The examples shown in SDK help and other places show using GDB. This seems inconsistent.
3. The default configuration automatically set up is for GDB (which is the one that wouldn't work).
This doesn't answer why the GDB version didn't work, but I do have a System Debugger configuration that does, so I can move forward.
12-26-2016 07:51 AM
12-29-2016 11:52 AM
How exactly did you launch an ELF using the System Debugger?
I ran into your exact error as well, but don't know how you managed the work around. It seems that there is no way to launch the ps7_init and the Elf file together.
If you or a moderator could chime in that would be so helpful!
12-30-2016 03:29 AM
I have similar problem, but with different approach.
I boot Linux with help of tcl script. Part of this script is:
the problem is inside this last line. I investigated a bit on this, and it turned out, that this function invokes another function, that has this line:
mwr -force 0XF8000008 0x0000DF0D
This is intended to unlock System Level Control Registers. Mysterious thing for me here is this "-force" part, as I couldn't find what is the purpose of it in docs. Without this "-force" everything is fine. In tcl files generated in previous versions of Vivado (at least 2016.1) there is no "-force".
Could someone from Xilinx comment on that?
12-30-2016 04:19 AM
01-03-2017 08:25 PM
I have posted a reply here.
To use system debugger, please refer to "Standalone Application Debug Using Xilinx System Debugger" section in SDK help
01-06-2017 03:07 AM
01-06-2017 03:55 AM
Create some project with PS, and just generate ps7_init.tcl file to configurate PS using Vivado 2016.4, and execute
function from this script.
You should notice, that in this file there is for example line:
mwr -force 0XF8000008 0x0000DF0D
And this "-force" breaks backward compatibility with xmd.
If it is not enough, there are my steps:
Use project adv7511 for Zedboard from Analog Devices:
Use latest branch (hdl_2016_r2), and compile it with Vivado 2016.2, and then again, with Vivado 2016.4.
Export to SDK (with bitstream), then open SDK. Sctipt should be generated automatically after a few seconds.
Maybe it is not a bug, but a feature, so that people move to xsdb? ;)
For those, that does not know how to move to xsdb, example script for configuring PS, and booting Linux with U-boot, that I was "-forced" to write(;)):
connect targets 2 #connect to first core rst fpga -f <path to system_top.bit>/system_top.bit source <path to ps7_init.tcl>/ps7_init.tcl ps7_init # for PS configuration ps7_post_config # for enabling level shifters between PL and PS, and de-asserting FPGA software resets. dow <path to u-boot.elf>/u-boot.elf con
Maybe not ideal, but works for me.
01-06-2017 08:21 AM
To answer the question of how to use system debugger--first the background. I build the PL project in Vivado (originally 16.2 then 16.3 and most recently 16.4). I export (including bitmap) and launch SDK. But I had previously never been able to use System debugger. It turns out that SDK creates the necessary configuration for GDB (which seems strange, since it is depreciated) but not for system debugger, so if you try to use system debugger it defaults to assuming that the project runs on Linux.
The solution is to click Run/Run Configurations. Click Xilinx C/C++ application (System Debugger) which will bring up a blank screen with some directions. Click the New Launch Configuration menu icon directly above the last click. It open a configuration screen where you can specify type (Standalone in my case) and point it to the platform, bitstream and initialization files. The Run button at the bottom will launch it on the target, and after than, Just clicking the Run As.. icon on the SDK tool bar will suffice.
For information sake, I tried to do the same thing with GDB (removing the pre-built one and replacing it) but was never able to make it work. Interestingly, it did not appear to be an SDK issue, as taking the hdf file to a 16.3 SDK produced the same error, and the hdf file comes from Vivado.