Nios II Dual Port RAM memory contents not what expected

[Altera_Forum]

Hi folks. I built a simple system using Qsys (packaged with Quartus Prime 15.1) with some onchip memory for cpu instruction and data, plus a separate dual port RAM (data width 32, 1024 bytes, base address 0x1000) for passing data back and forth between FPGA logic and CPU. The other components in the system are a uart, 50MHz clock and System ID component. Using a Terasic Cyclone V FPGA Starter Kit.  

 I initialize the RAM with a .hex file generated using the Quartus hex editor (word size 32, depth 256). For starters, just using the initialized memory and a simple application to read out the memory contents and printf to the uart. For some reason, only the last 124 addresses appear to provide the correct data and the rest is not instantly recognizable. Here's the code. Can anyone see why this is happening?  // dp_ram_test.c# include <stdio.h># include <unistd.h># include "system.h" int main() { int i=0; unsigned dp_ram_addr = 0; unsigned *dp_ram_ptr = 0; printf("Begin...\n"); printf("Starting at address 0x0000%x\r\n", DP_RAM_BASE); printf("Hex Addr (dec) : Contents\r\n"); printf("================= : ========\r\n"); for (i = 0; i < 1024; i++) { dp_ram_addr = DP_RAM_BASE + i; dp_ram_ptr = (unsigned *)(dp_ram_addr); printf("0x0000%x (%u) : %x %u\r\n", dp_ram_addr, dp_ram_addr, *dp_ram_ptr, *dp_ram_ptr); } return 0; }   The hex file (as .pdf) and log file of uart output are attached. Any help would be great. Thanks in advance.

[Altera_Forum]

Try incrementing your fetch address by the size of the quantity you are reading. I don't know if NIOS cares, but it's worth a try. Change i < 1024 to i < 256 and DP_RAM_BASE + i; to DP_RAM_BASE + 4*i;

[Altera_Forum]

Can you check whether the CPU is writing some values into the Dual port RAM that may corrupt the values? You can check at the bsp-editor to ensure that the linker does not mapped any data region into the dual port RAM.

[Altera_Forum]

--- Quote Start ---  Try incrementing your fetch address by the size of the quantity you are reading.  --- Quote End ---   This was correct, I changed my code to increment the address by 4 and this corrected my output. In my original code I was essentially reading the same location 4 times in a row.    --- Quote Start ---  Can you check whether the CPU is writing some values into the Dual port RAM that may corrupt the values? You can check at the bsp-editor to ensure that the linker does not mapped any data region into the dual port RAM.  --- Quote End ---   Thank you. This solved the "unexpected data" part of the problem. I had originally mapped .rodata and .rwdata to the dp_ram because I did not have enough understanding of the bsp. Once I remapped everything to the onchip memory, life is good again.