Dowloading elf process failed

[Altera_Forum]

I have a simple Nios 2 program with a nios 2 cpu and off chip SRAM. I use the University program IP core SRAM controller with a de2 board. I can generate the system successfully but I get several instances of the following warnings: 

 Warning: sram: get_generation_setting is deprecated, please use get_generation_property instead  Warning: sram: get_project_property quartus_project_name is unsafe; this component should not depend on or modify the project   When I build my software project and run as nios hardware a message box pops up informing me that the "downloading elf process failed". This only occurred in my system with the addition of the sram controller so I believe the problem may be caused by the warnings above.  If anyone has any idea what the cause of this error could be or how to fix the warnings generated by the sopc builder your help would be greatly appreciated.   Chase

[Altera_Forum]

Hi, 

 we have got a similar problem. We wanted to switch from NIOS IDE 8.1 to the "new" NIOS EDS 10.0.  Everything works fine, until we try to download our software to the board. We get following error message:    --- Quote Start ---   Verifying 02000020 ( 0%) Verifying 020070A4 (67%) Verifying 02008EC8 (87%) Verifying 03700000 (99%) Verify failed between address 0x3700000 and 0x370001F Leaving target processor paused   --- Quote End ---  At 0x03700000 - 0x0370001F the altera_avalon_cfi_flash is located. I assume it is the "reset"-region.  In our Design we have got SRAM and SDRAM. But obviously downloading to this regions works, because verifying pass. I have to add that we compiled the Hardware-Design with Quartus 8.1 and used the *.sopcinfo file of that version. I hope this isn't a problem.  @Chase: Which excact output do you get, when you try to download the software? Does the Verify fail? Which NIOS EDS Version are you using?  Regards  Phil

[Altera_Forum]

Phil, 

I am using Nios 2 EDS vs. 9.1 sp2. Verifying did fail in the address of my SRAM. This is what makes me think that the warnings I received in SOPC Builder about the Univeristy Program SRAM controller core are related to the issue. I am going to try editing the tcl scripts for the SRAM controller according to the warnings I was given and see if I can solve the issue. I will post any progress.

[Altera_Forum]

Thanks for the informations. So I would assume that we have different problems after all, because your Design fails in SRAM region. 

 But I would be appreciated if you could post any progress.

[Altera_Forum]

Well I edited the TCL files and the warnings in SOPC have gone but the memory verification continues to fail. I believe there is some timing issue going on. If I find a fix I will post it. 

 Chase

[Altera_Forum]

Phil - 

I have the same issue as you. I have a prototype pcb I am in debug with and there are a myriad of issues. The design has a 3c120 ethernet, 2 sdram banks and a cfi flash interface. All of the interfaces seem to have issues so I made a stripped down version of the embedded system and compiled "hello world niosii" targeting a 32Kx32 internal block memory (defined as a rom) theres also 32kx32 data ram. Idea here is to get something to load and run code, then write diags to debug the rest.  I added a timer based task that flashes a led on via a pio every 3 seconds  I incorporate the .hex file into the build and assume it's picking it up and building it into the .sof  The system does not boot - when I try to just send the elf code I get  Using cable "USB-Blaster [USB-0]", device 1, instance 0x00 Pausing target processor: OK Reading System ID at address 0x18004D40: verified Initializing CPU cache (if present) OK  Downloading 030C0000 ( 0%) Downloading 030C0120 ( 0%) Downloading 030D0000 (70%) Downloaded 91KB in 1.6s (56.8KB/s)  Verifying 030C0000 ( 0%) Verify failed between address 0x30C0000 and 0x30C001F Leaving target processor paused   look similar?

[Altera_Forum]

Hi, Pillemann 

I assume in 03700000 flash is maped  Plz read the data sheet of your flash and find out the maximum write time for the flash.Once you got the write time ,open the SOPC builder and double click on the CFI Flash give the wait state as the write time.(If you don't know the wait state then give an arbitrary value setup and hold time =1 cycle and wait state=50 cycle(the unit should be in cycles)).

[Altera_Forum]

Hi, 

 sorry that it take me so long for replying. I was on vacation......:)  Meanwhile our hardware engineer (responsible for the hardware designs) created (us software engineers) a running design. So now, we can download software with NIOS 10.0 eds using the hardware design mentioned in previous posts.  Why does the design works now: 1.) The not running hardware design was compiled with Quartus 8.1 (as mentioned above). Why that??? Answer: The reason for that is located by the new Quartus 10.0, which is not able to cope with dual-purpose-IOs yet and therefore is not able to compile such a design successfully. (NOTE: ALTERA is already aware of that and they are working on the problem.)  2.) Our hardware engineer recently uses a workaround in order to compile the dual-purpose-IOs with the Quartus 10.0. This works fine. Using the newly created hardware image (Quartus 10.0) we are able to download software to our test board.  Our dual-purpose-IOs are used for the FLASH.    @AjeeshAzeez: Correct. Flash is located at this address. Don't need to look up max write time, because it's running now. But thanks for helping.  @crayner: Yeah, same error message as ours. Is your flash located at this region? In our case it was. Which Quartus Version was used for compiling? Have you also dual-purpose-IOs in your design?

[Altera_Forum]

Hi, 

 Some info that may help: for the issue discussed above please note the document : "Nios II Embedded Design Suite Release Notes and Errata", errata on page 55, " issue : Error Running Nios II Project: ‘Downloading ELF Process failed’ ".   It solved the same problem described above in my case.    Dani 

[Altera_Forum]

Two of those comments in the release notes were biting me.. 

Changing memory size isn't caught by the system..  I fixed it by deleting the bsp project and regenerating it every time I update the sopc design..  The other thing that bit me is that I had nowhere near enough ram for the project, and at first the tool didn't warn me, it just failed to download the elf file.  I started playing with the internal memory size I added, suddenly the Nios Eclipse tools warned me I didn't have enough ram...  Sigh...

[Altera_Forum]

Hi, 

 Nios II SBT for Eclipse detects insufficient memory errors.  Hope this helps.  Vaibhav