Forum Discussion

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

Debug problem - code loading at incorrect address

I'm debugging a standalone application on our target hardware using the NIOS2 9.1 SP1 eclipse debugger. The code is being loaded at an incorrect address (a frame buffer in our sopc build), and fails verification as that memory is overwritten. Where does the debugger get the address for the executable to be loaded?

Thanks in advance!

Here's the debugger output:

Using cable "USB-Blaster [USB-0]", device 1, instance 0x00

Processor is already paused

Initializing CPU cache (if present)

OK

Downloading 00000020 ( 0%)

Downloading 14000000 ( 0%)

Downloading 14010000 (48%)

Downloading 14020000 (96%)

Downloaded 134KB in 2.3s (58.2KB/s)

Verifying 00000020 ( 0%)

Verifying 14000000 ( 0%)

Verify failed between address 0x14000000 and 0x1400FFFF

Leaving target processor paused

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    i believe .sopcinfo is where the Nios tools will get the base addresses of the components from. make sure its up to date.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I searched the sopcinfo file for the address and found several instances of base_address set to 14000000 - all of them for pipeline bridge components.

    The map file contains:

    --- Quote Start ---

    *(.text .stub .text.* .gnu.linkonce.t.*)

    .text 0x14000000 0x48 C:/TWS_bsp//obj/HAL/src/crt0.o

    0x14000000 _start

    .text 0x14000048 0x15c obj/source/battery.o

    0x14000048 getBatteryLevel

    .text 0x140001a4 0x3c obj/source/conditions.o

    etc...

    --- Quote End ---

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I noticed in the bsp summary.html that the alt_fb_ddr was used for all code segments. Running the bsp editor, changing the base addresses to alt_mem_ddr, and regenerating fixed this problem