Verification Error when using SSRAM for NIOS II

[Altera_Forum]

When I've been going to load my code (.ELF file) onto the NIOS II, I'm getting an SREC verification error. I was originally using on-chip memory for the NIOS II, but I have changed it so that I am using the SSRAM on my DE2-70 as the main memory for NIOS. I still do have an on-chip memory instantiated, but it is being used for something else. 

 I've checked these forums thoroughly and could not find a solution. I should state also that I have verified and tested the SSRAM is working properly for reads and writes by creating an SSRAM test program while using the on-chip memory as the main memory for NIOS. After this I changed it back to use the SSRAM as the main memory for NIOS in the SOPC builder.  Compilation in the NIOS II 9.1 IDE completes without errors, and it states I have 1995kb or so free for stack & heap after compilation which is correct considering there is 2MB of SSRAM.  Still all I'm getting is a verification error when attempting to load using the Altera Monitor Program (and the memory address of the SSRAM is correct when it comes up with the error during loading).   Any troubleshooting ideas anyone could offer would be much appreciated, thanks!

[Altera_Forum]

Check that the 'program' sections in the ELF image (look at the output of 'objdump -p') match the addresses of the memory areas as seen by the Nios Cpu (assuming you are using the JTAG debugger to load your code). 

The linker script may be doing something else.

[Altera_Forum]

Thank you very much for the response. 

 Looking at the output of objdump: Program Header:  LOAD off 0x00000094 vaddr 0x00200020 paddr 0x00200020 align 2**0  filesz 0x0000b704 memsz 0x0000b704 flags r-x  LOAD off 0x0000b798 vaddr 0x0020b724 paddr 0x0020b724 align 2**0  filesz 0x00001a2c memsz 0x00001c40 flags rw-  LOAD off 0x0000d1c4 vaddr 0x00420000 paddr 0x00420000 align 2**0  filesz 0x00000020 memsz 0x00000020 flags r-x There are 3 items here, as opposed to the usual 2 when I build a project using only onchip memory with no SSRAM. The last one at 0x00420000 is the address of the onchip, so I'm assuming it's listed because the onchip is still being used as the reset vector in my configuration in SOPC builder. For what it's worth I've tried using the SSRAM configured as both the reset and exception vector, but that still resulted in the same problem shown in the monitor program output screenshot. Looking further at the objdump file, I can see the mem addresses of the assembly output of the program do correspond correctly with the SSRAM. I'm not sure where to go from here? I've attached some other configuration screens if they may be of any use.

[Altera_Forum]

Also possibly interest, the objdump for the project where the SSRAM is used as both the exception and reset vector. With all the linker sections in the BSP editor set to be the SSRAM: 

 architecture: nios2, flags 0x00000112:  EXEC_P, HAS_SYMS, D_PAGED  start address 0x002001c4   Program Header:  LOAD off 0x00000074 vaddr 0x00200000 paddr 0x00200000 align 2**0  filesz 0x0000b724 memsz 0x0000b724 flags r-x  LOAD off 0x0000b798 vaddr 0x0020b724 paddr 0x0020b724 align 2**0  filesz 0x00001a2c memsz 0x00001c40 flags rw-   Sections:  Idx Name Size VMA LMA File off Algn  0 .entry 00000020 00200000 00200000 00000074 2**5  CONTENTS, ALLOC, LOAD, READONLY, CODE  1 .exceptions 000001a4 00200020 00200020 00000094 2**2  CONTENTS, ALLOC, LOAD, READONLY, CODE  2 .text 0000b078 002001c4 002001c4 00000238 2**2  CONTENTS, ALLOC, LOAD, READONLY, CODE  3 .rodata 000004e8 0020b23c 0020b23c 0000b2b0 2**2  CONTENTS, ALLOC, LOAD, READONLY, DATA  4 .rwdata 00001a2c 0020b724 0020b724 0000b798 2**2  CONTENTS, ALLOC, LOAD, DATA, SMALL_DATA  5 .bss 00000214 0020d150 0020d150 0000d1c4 2**2  ALLOC, SMALL_DATA  6 .ssram_0 00000000 0020d364 0020d364 0000d1c4 2**0  CONTENTS  7 .onchip_memory_NIOS_sys 00000000 00420000 00420000 0000d1c4 2**0  CONTENTS  8 .comment 00001080 00000000 00000000 0000d1c4 2**0  CONTENTS, READONLY  9 .debug_aranges 00000bd8 00000000 00000000 0000e248 2**3  CONTENTS, READONLY, DEBUGGING  10 .debug_pubnames 0000113b 00000000 00000000 0000ee20 2**0  CONTENTS, READONLY, DEBUGGING  11 .debug_info 00021a87 00000000 00000000 0000ff5b 2**0  CONTENTS, READONLY, DEBUGGING  12 .debug_abbrev 00007277 00000000 00000000 000319e2 2**0  CONTENTS, READONLY, DEBUGGING  13 .debug_line 00012916 00000000 00000000 00038c59 2**0  CONTENTS, READONLY, DEBUGGING  14 .debug_frame 00001588 00000000 00000000 0004b570 2**2  CONTENTS, READONLY, DEBUGGING  15 .debug_str 0000214c 00000000 00000000 0004caf8 2**0  CONTENTS, READONLY, DEBUGGING  16 .debug_alt_sim_info 00000030 00000000 00000000 0004ec44 2**2  CONTENTS, READONLY, DEBUGGING  17 .debug_ranges 00000590 00000030 00000030 0004ec74 2**0  CONTENTS, READONLY, DEBUGGING  18 .cpu 00000005 00000000 00000000 00051e9e 2**0  CONTENTS, READONLY  19 .simulation_enabled 00000001 00000000 00000000 00051ea3 2**0  CONTENTS, READONLY  20 .stderr_dev 0000000b 00000000 00000000 00051ea4 2**0  CONTENTS, READONLY  21 .stdin_dev 0000000b 00000000 00000000 00051eaf 2**0  CONTENTS, READONLY  22 .stdout_dev 0000000b 00000000 00000000 00051eba 2**0  CONTENTS, READONLY  23 .sopc_system_name 0000000e 00000000 00000000 00051ec5 2**0  CONTENTS, READONLY  24 .quartus_project_dir 00000021 00000000 00000000 00051ed3 2**0  CONTENTS, READONLY  25 .jdi 00004c09 00000000 00000000 00051ef4 2**0  CONTENTS, READONLY  SYMBOL TABLE:  00200000 l d .entry 00000000   00200020 l d .exceptions 00000000   002001c4 l d .text 00000000   0020b23c l d .rodata 00000000   0020b724 l d .rwdata 00000000   0020d150 l d .bss 00000000   0020d364 l d .ssram_0 00000000   00420000 l d .onchip_memory_NIOS_sys 00000000   00000000 l d .comment 00000000   00000000 l d .debug_aranges 00000000   00000000 l d .debug_pubnames 00000000   00000000 l d .debug_info 00000000   00000000 l d .debug_abbrev 00000000   00000000 l d .debug_line 00000000   00000000 l d .debug_frame 00000000   00000000 l d .debug_str 00000000   00000000 l d .debug_alt_sim_info 00000000   00000030 l d .debug_ranges 00000000    I experience the exact same problem with the monitor program failing to verify the code after loading it.

[Altera_Forum]

Add for what it's worth, if it even makes any difference, I tried running it in the legacy IDE with the same results.

[Altera_Forum]

As far as I can tell, the JTAG downloader writes to memory from the nios cpu (while executing code out of the JTAG block). So, on the face of it, that configuration and image should load. It is rather a shame that it doesn't give you the offset of the failure, and the invalid data. 

IIRC one of the JTAG debugger windows has a gdb command prompt. It might be possible to use that to do read/write verification of the SSRAM in that configuration.

[Altera_Forum]

Thank you for the response again. 

 Is there another JTAG debugger other than the one accessible from the Command Shell? I've attached a screenshot of my results from EDS command line, which are the same unfortunately. There weren't any extra debugging options available to help with this situation either.