Quartus 5.0 and Nios Eval 5.0

The nios2-download which comes with the 5.0 kit is the first one which reads back the data it's just downloaded to check that it has been correctly written into the memories.

If you are getting this error then the data read back didn't match up with the data written. There are two possible explanations.

The first is that the elf file is incorrectly trying to initialise areas in the address map which aren&#39;t really memories. You should use `nios2-elf-readelf -S <elffile>` to find out which areas of memory are being initialised - nios2-download will write all sections containing the A flag to the target.

The second is that there is something wrong with your memories and they really aren&#39;t keeping the data which has been written into them. Clock frequencies and timing would be my first suspects here.

Thank you Wombat,

The option that the memory is not holding the data is not the answer in wy case. Everything works (and worked already a long time) with the 4.2 version. And also if I use the slow method of loading the data (GERMS monitor), the program works fine.

The list of sections is a bit confusing to me. I&#39;m not a expert in this area.

Is it possible to disable the verify operation with a command line option?

Section Headers:

[Nr] Name Type Addr Off Size ES Flg Lk Inf Al

[ 0] NULL 00000000 000000 000000 00 0 0 0

[ 1] .exception PROGBITS 00004020 000134 00017c 00 AX 0 0 4

[ 2] .intram PROGBITS 000041a0 0002b0 0003e8 00 WAX 0 0 8

[ 3] .text PROGBITS 00100000 000698 02a3a8 00 AX 0 0 8

[ 4] .ctors PROGBITS 0012a3a8 02aa40 000018 00 WA 0 0 4

[ 5] .dtors PROGBITS 0012a3c0 02aa58 000014 00 WA 0 0 4

[ 6] .rodata PROGBITS 0012a3d8 02aa6c 002ac4 00 A 0 0 8

[ 7] .data PROGBITS 0012ce9c 02d530 0007ac 00 WA 0 0 4

[ 8] .sdata PROGBITS 0012d648 02dcdc 000140 00 WAp 0 0 4

[ 9] .got PROGBITS 0012d648 02e07c 000000 00 W 0 0 1

[10] .sbss NOBITS 0012d788 02de1c 000040 00 WAp 0 0 4

[11] .bss NOBITS 0012d7c8 02de1c 001a30 00 WA 0 0 8

[12] .debug_abbrev PROGBITS 0012f1f8 02e07c 00b86f 00 0 0 1

[13] .debug_info PROGBITS 0013aa67 0398eb 07cc92 00 0 0 1

[14] .debug_line PROGBITS 001b76f9 0b657d 034706 00 0 0 1

[15] .gcc_except_table PROGBITS 001ebe00 02de1c 000254 00 WA 0 0 4

[16] .debug_frame PROGBITS 001ec054 0eac84 005e5c 00 0 0 4

[17] .debug_pubnames PROGBITS 001f1eb0 0f0ae0 0069fb 00 0 0 1

[18] .debug_aranges PROGBITS 001f88ab 0f74db 001528 00 0 0 1

[19] .debug_str PROGBITS 001f9dd3 0f8a03 00b6ff 01 MS 0 0 1

[20] .comment PROGBITS 002054d2 104102 000bdd 00 0 0 1

[21] .debug_ranges PROGBITS 002060af 104cdf 000af0 00 0 0 1

[22] .reset PROGBITS 00206ba0 02e070 00000c 00 AX 0 0 4

[23] .shstrtab STRTAB 00000000 1057cf 0000f4 00 0 0 1

[24] .symtab SYMTAB 00000000 105cd4 005e30 10 25 1b2 4

[25] .strtab STRTAB 00000000 10bb04 007267 00 0 0 1

Key to Flags:

W (write), A (alloc), X (execute), M (merge), S (strings)

I (info), L (link order), G (group), x (unknown)

O (extra OS processing required) o (OS specific), p (processor specific)

Wombat,

Indeed, there was a section mapped to a region that didn&#39;t exists.

But, I&#39;m now trying to use a tightly coupled instruction memory (with the standard processor). And again it fails, right at the first byte to load to the tightly coupled memory.

Any idea?

Ok, I forgot to connect the cpu data master to a second slave port on the memory, so it can load the data.

So for the moment it is running.

Stefaan