Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
12435 Discussions

Debugging from memory and reset vector selection

Honored Contributor II

What is the guideline for setting the cpu reset vector when debugging using direct memory load (Eclipse Debug As Nios Hardware)? Does it vary based on specific target hardware / generation? 


My standard procedure was to build a SOPC/QSYS system with reset vector pointing to RAM, debug the application, then rebuild the system and application with the reset vector pointing to the serial flash controller (or whatever flash device), and flash it. Not optimal, since you're not debugging the final .sof 


Then I found that with a new design (Stratix V w/ EPCQ) that I could successfully load memory and debug without changing the reset vector temporily to RAM. (i.e reset vector is always in the final desired location) 


So now I'm confused about when the sub-optimal debug method is required. 


For my current project (DE0-Nano w/ Cyclone IV & EPCS) debug works fine if the reset vector points to RAM. 

With the CPU reset vector set to the EPCS controller I'm getting a ELF verify failure ("Downloading ELF Process failed") in the EPCS controller section. 


What's the full story, and where is it best documented?
0 Kudos
2 Replies
Honored Contributor II

I'm having the same issue. I'm using Quartus 13.0 SP1 on a Cyclone V / EPCQ project.

Honored Contributor II

I'm going to bump this back up as I'm hitting the same problem and no answer has been given. 


My design flow at the moment is to put the reset vector in ram and use this to debug my code. Once I'm happy, I recompile the hardware design, this time putting the reset vector in flash. I then program the flash with the new FPGA image and software image and test. Unfortunately, this then stops the debugger from working (ELF verify fail as below) so to debug I need to switch back to the reset vector being in ram. All a bit of a pain. 


This all appears to be non optimal and feels likely that I'm doing something wrong. 


Any ideas? 




ELF Verify fail: 

Verifying 00000020 ( 0%) 

Verifying 0000A580 (82%) 

Verifying 09720000 (99%) 

Verify failed between address 0x9720000 and 0x972001F 

Leaving target processor paused