Forum Discussion
Honored ContributorDownloading 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_ForumThe 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
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
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--- 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
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
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
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
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:
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...Using cable "DE-SoC ", device 2, instance 0x00 Resetting and pausing target processor: FAILED Leaving target processor paused
