Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

Downloading Elf Process failed

Help. I went home last night with everything working fine. I came in this morning and can't get the Nios II processor embedded in my Stratix III FPGA to download from the Eclipse environment.

I am able to successfully program the FPGA from the Quartus II programmer tool through a USB Blaster interface. When I then switch to Eclipse to download/debug the CPU I get a "Problem Occurred" popup dialog that says "'Launching Hardware' has encountered a problem. Downloading Elf Process failed". The dialog (even under "details") does not provide any useful information to help understand why it failed.

In the Eclipse Console window I get the following lines:

Warning: trying to use little-endian srec with big-endian hardware

Using cable "USB-Blaster [USB-0]", device 1, instance 0x00

Resetting and pausing target processor: FAILED

Leaving target processor paused

The first line looks like a good candidate, but still...a complete lack of useful information. It does not specifically identify the srec file in question. That file must have been automatically generated by the tool chain (because I certainly haven't manually created any srec files). How did the file get configured to be little-endian? How did the hardware get configured to be big-endian? And how did this change overnight?

Any suggestions for how to resolve this would be appreciated.

8 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    The little-endian/big-endian error message has gone away. Now I just get this in the Eclipse Console window:

    Using cable "USB-Blaster [USB-0]", device 1, instance 0x00

    Resetting and pausing target processor: FAILED

    Leaving target processor paused

    No indication of why it failed except that it seems to be during the elf download.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Caused by a hardware issue. There's a pretty broad list of possibilities, but I've seen it most commonly when I'm not supplying a system clock or reset properly.

    The message is just saying that the host side software tried to communicate with the processor and failed.

    --slacker
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    That was it. I had made an innocuous change to the reset signal to two off-chip devices. I undid that change and now things work. I can't say that what I changed makes sense (since the on-chip functions, including the CPU, are unaffected), but it works.

    Thanks for taking the time to reply.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    --- Quote Start ---

    That was it. I had made an innocuous change to the reset signal to two off-chip devices. I undid that change and now things work. I can't say that what I changed makes sense (since the on-chip functions, including the CPU, are unaffected), but it works.

    Thanks for taking the time to reply.

    --- Quote End ---

    Hi

    I'm currently experiencing the same problem you had. Where did you make those changes? In the .bdf file or in the PLL component in the SOPC builder?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    In my case the change was in the top-level file that hooks everything together. The real culprit was that I tied the Nios reset to a reset output that drove the clock generator chip that was providing the base clock to the FPGA. So when the development tools tried to reset the Nios processor it also reset the clock generator chip, which temporarily incapacitated the FPGA. Oops.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Hi,

    i had the same problem. In my case I had an external PLL which was resetted, too. Maybe it took to much time to get a lock again and the Connection failed. I solved it by not allowing the system to reset before downloading the ELF File.

    Its a checkbox in the IDE under Run../Run Configuration/Target Connection/"Reset The Selected Target System". Untick it and it works. ;)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    Hi,

    I'm also facing similar issue while running a simple hello world project through 'Nios II Hardware configuration'. Please see the attachment for details.

    Thank you

    Babloo
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    I had a similar problem, albeit in a different context. I did the exercise in the University Program tutorial introduction to the altera qsys system integration tool (https://www.altera.com/support/training/university/materials-tutorials.html) and everything went fine until I started the Monitor Program, loaded the generated system onto the FPGA and compiled the assembly program. But then, upon trying action Load, to load the .elf file, I got the following: 

    Using cable "DE-SoC ", device 2, instance 0x00
  Resetting and pausing target processor: FAILED
  Leaving target processor paused

    The culprit was the fact that I had forgot to import the DE1_SoC.qsf pin assignments into lights.qsf, before compiling the generated system in Quartus...