Forum Discussion

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

Debugging from memory and reset vector selection

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?

2 Replies

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

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

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

    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