Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12627 Discussions

Accessing SDRAM from program in OCRAM in Debugging

Honored Contributor II



I am using the Cyclone V SoC development board in a project that will be using the HPS system. I have been struggling to get the board working in the way I expect it to.  


My current issue is that I am not sure how to access the SDRAM while running a program from the OCRAM when using the debugger. There don't seem to be guides specifying how to do this specifically. I think the way I have it configured now places the program into the SDRAM and runs from there, but I can't say for certain that this is happening.  


I can access some addresses in the SDRAM range by just reading and writing to that memory location, but not for many; after a few this just returns garbage and eventually hangs the whole system.  


I attempted to run the sample project "Altera-SoCFPGA-HardwareLib-DMA-CV-GNU" and it always fails setting up data for the second test.  


I'm sort of at a loss and any assistance with understanding 1) how to access that portion of the memory map properly and 2) how to specify where to run programs when using the debugger would be greatly appreciated.
0 Kudos
4 Replies
Honored Contributor II

Here is some documentation that describes the memory map: 

See Figure 1-3 

See the Address Filtering registers 

See page 9-2 for a diagram of the two ports coming out of the L2, M1 and M0. These are important for the Address Filter registers. 

See page 7-26 for the remap register 


The MPU memory map is controlled by several registers: 

1) remap register, 0xff800000 

2) L2 address filter registers, 0xfffefc00 and 0xfffefc04 


It would help if you described more of your setup -- are you using the preloader, the bootloader, Linux, baremetal, 

what sample projects are you starting from, all of the steps you are doing leading up to point where you see the problem.
0 Kudos
Honored Contributor II


0 Kudos
Honored Contributor II

I am still a novice, but I would check the Makefile in the project to see what linker script is being used. 

In the DMA example that I have, the Makefile content looks like this: 

LINKER_SCRIPT := cycloneV-dk-ram-hosted.ld 


You want to find where the file cycloneV-dk-ram-hosted.ld is located. In my case, it's located in the SocEDS 

installation directory. It could also be in the Project directory. 

$ find . -name 'cycloneV-dk-ram-hosted.ld' -print 




Inside that linker file, it specifies how the various sections of the program are laid out. In my case, it shows that the 

text of the program is located in SDRAM: 



boot_rom (rx) : ORIGIN = 0xfffd0000, LENGTH = 64K 

oc_ram (rwx) : ORIGIN = 0xffff0000, LENGTH = 64K 

ram (rwx) : ORIGIN = 0x100000, LENGTH = 1023M 


.text : 


} >ram 


There will be other linker files in the SoCEDS installation directory which use the On-chip RAM for running programs, like this one:  



There is at least one sample Project in my SocEDS installation that uses the on-chip RAM: 




ifeq ($(filter $(BOARD),arriav cyclonev),$(BOARD)) 

LINKER_SCRIPT := cycloneV-dk-oc-ram-hosted.ld 


I am not sure I can help with the freeze condition, but maybe you can try this simpler HelloWorld sample, 

and see if that works.
0 Kudos
Honored Contributor II

That's a good catch! I see that referenced in the Makefile of the sample project. I'll try changing that to the oc-ram function and give it a shot. Thank you so much.

0 Kudos