Actions
Forum Thread Details
  • State Not Answered
  • Replies 7 replies
  • Subscribers 356 subscribers
  • Views 926 views
  • Users 0 members are here
Related

MicroZed Run .elf issue

Former Member

I am currently building a system to run on the MicroZed 7020 board. My system consists of an FPGA design and a baremetal application. I've used Vivado 2014.4 but a week ago I decided to try the new Vivado 2016.1. I didn't realize at that time that I need 2016.1 compatible board definition files. I went through the hazzle of updating everything in my design and got the bitstream generated. After some time spent with the SDK and multiple tries to run my app I remembered the board definition files and noticed that there isn't ones for 2016.1. So I decided to go back and continue with my 2014.4 version. Now when running my system with the 2014.4 version I got this weird problem. When programming the FPGA and running my application for the first time after a power-cycle everything goes smoothly. When I want to relaunch the app it seems that the FPGA is reset even though I haven't specified the run configurations to reset the whole system. The launch is interrupted with the message

No Target with ID 64 in the System

Unexpected error while launching program.
java.lang.RuntimeException: Failed to download ELF file

Cannot access JTAG-DP: invalid ACK value (0x00, expected=0x02)
Error Address = 0x0017b000, Size = 0x00000004

at com.xilinx.sdk.targetmanager.internal.TM.downloadELF(TM.java:666)
at com.xilinx.sdk.debug.core.internal.AppRunner.run(AppRunner.java:129)
at com.xilinx.sdk.debug.core.XilinxAppLaunchConfigurationDelegate.runApplication(XilinxAppLaunchConfigurationDelegate.java:605


If I reprogram the FPGA and relaunch the app SDK thinks I have another session in progress and I need to relaunch SDK.

If I modify the run configurations so that SDK resets the whole system and programs the FPGA on every relaunch I have to relaunch twice as the first relaunch is always interrupted with the message "Unexpected error while launching program: Failed to download the bit file"

This is so impractical that I uninstalled 2016.1 and reinstalled 2014.4 hoping that it would fix the issue. No luck. Any ideas what trace did the 2016.1 leave on my computer/board?

BR,
Esa


  • 0

    Hi there,

    *Did you use a base reference design?
    *Are you certain you removed all the modifications you made when trying to use 2016.1?
    *Can you first make a backup of your project folder, then try to delete all Vivado generated files.  Next rebuild your project in Vivado 2014.4?  It is quite possible that there are binaries or configuration files generated by Vivado that are incompatible going backwards to 2014.4 from 2016.1.

    --Dan

  • 0

    Hi there,

    I wanted to also post that this seems very similar to another post:
    http://zedboard.org/content/no-target-id-64-system

    Are you initializing the PS7 with ps7_init functions?  This could also cause your described symptoms.

    --Dan

  • 0

    Hello Esa,

     

    I just tried a 2016.1 design for the MicroZed 7020 (just a basic design) and exported to 2016.1 SDK. I used the 2015.4 MicroZed 7020 board defintion files. You should be able to install them in the Vivado 2016.1 install OK. Just follow the 2015.4 instructions, using the 2016.1 installation directory.

     

    I build the canned 'peripherial test' application. I was able to load and run/debug the the application with no issues. I did click the 'disconnect' icon on the Debug tool bar before relaunching the application in the SDK debugger the second time. 

     

    Run ps7_init and Run ps7-post_config were checked in the Debug configuration.

     

    You might want to try one of the 'canned' SDK applications to verify that your board and Vivado/SDK installation are all good before trying your application.

     

    -Gary

  • 0 in reply to drozwood90

    Thank you Dan for your response,

    My Vivado Block design uses the basic Zynq Processing System which is connected to AXI Lite IPs which I have generated from my VHDL sources. I think that the SDK application project may have been built on the Hello World -example rather than an Empty Project.

    When moving to 2016.1 I archived my 2014.4 designs and updated all the IPs after which I was able to generate the bitstream. When I left the 2016.1 alone I extracted the 2014.4 version and continued with that one. It didn't work and so I packaged all the IPs and built the system block design with the 2014.4 from scratch. I exported the new hardware and made a new SDK project but it didn't make any difference. So to my knowledge there should not be any 2016.1 files in my project.

    -Esa

  • 0 in reply to drozwood90

    Yes, the ps7_init.tcl is specified and ps7_init and ps7_post_config boxes are checked in the Target Setup -tab. Is it possible that the .tcl is generated incorrectly?

    -Esa

  • 0 in reply to Former Member

    Hello Gary and thank you for your response,

    Actually I tried the 2015.4 board definition files on my 2016.1 installation and I could not get my system running. I'm not sure in which part of the processor reset the error appeared in 2016.1 as I was able to program the FPGA (blue led on) but I couldn't get the application to launch at any point. Not sure If should package all my designs in 2016.1 from scratch and try again as I'm a bit uncertain about the IP Update. Then again how could that have an effect on the SDK application...?

    -Esa

  • 0

    Hello Esa,

     

    I don't have any information on your designs or the IP you use but there can be issues as you move to newer versions of the Xilinx tools. If you are starting your design now I would suggest starting with the latest tool suite, 2016.1 in this case.

     

    As mentioned above I was able to verify that the 2015.4 board files work with 2016.1. It is possible that your 2016.1 Vivado/SDK installation download was corrupted. You should always check the MD5 sum of the downloaded file prior to performing the installation. I would suggest implementing one of the 'canned' SDK applications, such as the peripheral test, for your exported hardware design to verify your tool installation and hardware setup.

     

    -Gary