Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12603 Discussions

Debugging from memory and reset vector selection

Altera_Forum
Honored Contributor II
‎04-04-2014 03:35 PM
1,566 Views

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

Link Copied

2 Replies
Altera_Forum
Honored Contributor II
‎04-24-2014 09:30 PM
412 Views

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

0 Kudos
Copy link
Altera_Forum
Honored Contributor II
‎02-25-2016 12:32 PM
412 Views

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
0 Kudos
Copy link
Reply

Community support is provided during standard business hours (Monday to Friday 7AM - 5PM PST). Other contact methods are available here.

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

For more complete information about compiler optimizations, see our Optimization Notice.