Intel® FPGA University Program
University Program Material, Education Boards, and Laboratory Exercises
1198 Discussions

How can i use SRAM properly with NORMAL C library?

Altera_Forum
Honored Contributor II
1,395 Views

Hello. I've some memory problems while using DE1 board(with cyclone 2) 

 

I succesfully created a system and make an example of binary counter(the one that given in the official altera web site-niosII_hardware_tutorial-)That sample requires small C library so no problem occured. I tried a little different code. I tried to use scanf func so i have to use full C library. One of my friends actually used it. In his project he used scanf, leds and sram(for the memory problem). He pushes 1,2,3,4 from the keyboard and related led lights up(very simple and basic program :D ). I tried the same but i cannot be able to use sram. To add sram to my system i used Avalon-MM Tristate Bridge (i am able to associate with nios processor "only" with this component. Non of the other parts worked :\). In the end i created a system and defined required input output,clock,vcc etc and assinged default pins(which is givven in the CD that contains samples) to them. I opened it in Nios and wrote the code. The problem starts here.(I apologize for the looong story above but i have to explain :P ). When i try to compile my code without C++ support and "with" normal C, it gives memory error.(Smthing about overlappings.) Eventhough my sistem didn't contain an onchip memory, i have an extra error about inadequate onchip memory.(something like "26 kb more onchip memory required") 

Thus, What should i do? As title states How can i use SRAM properly with NORMAL C library? If you can give me some sample codes and some useful instructions about how to use memory parts , it would really help on my study. 

 

Again any help would be great!! 

 

Thank you for reading that long enty and thank this very moment for your comming answers :) 

 

-srht
0 Kudos
6 Replies
Altera_Forum
Honored Contributor II
678 Views

The error means that some part of your code doesn't fit in the memory you are mapping it to. Whereas the small C library fit. 

Check the linker description file and find where all code sections are supposed to be. And if there is any reference to onchip memory. if you don't use ldf, check in the system library properties. 

 

I don't know the inner workings of the normal C library, but this could also indicate that it contains a function or variable that requires onchip memory; or, conversely, that can't reside on sram, although this is very strange. 

 

Regards 

Cris
0 Kudos
Altera_Forum
Honored Contributor II
678 Views

Thank you for your answer but i think i solved the problem. 

Because I'm really careless i missed some "really" important points :P(that's my foolishness) 

Now there is an another error :D About downloading elf process. I'll try a little than ask again ;D 

 

Anyway you've been helpful thank you again Cris 

 

-srht
0 Kudos
Altera_Forum
Honored Contributor II
678 Views

I am having a problem with accessing externa SRAM on DE2 board using C program in NiosII IDE. I am using the SRAM controller provided by the University Program. As shown in the snapshot, I have two dedicated on chip memory, one for data and one for instruction. I also have LED to display data and switch to control which data must be displayed. The snapshot of the SOPC is attached. The instruction and data memory are both 32 bit wide.  

Now I write a simple C code to write and then read from the SRAM. Following is the code 

# include "sys/alt_stdio.h"# include "system.h"# include "altera_avalon_pio_regs.h"# include <stdio.h># include <alt_types.h># include <io.h># include <string.h> 

# include "sys/alt_dma.h" 

 

int main() 

{  

int count; 

int offset; 

int pattern; 

pattern = 4; 

int delay; 

 

for (offset = 0; offset < 192; offset+=2) 

printf("Hello from Nios II 1!%d %d\n", offset, pattern); 

IOWR_32DIRECT(SRAM_BASE, offset, pattern); 

 

printf("Hello from Nios II!\n"); 

pattern=1; 

 

for (offset = 192; offset < 384; offset+=2) 

printf("Hello from Nios II 2! %d %d\n", offset, pattern); 

IOWR_32DIRECT(SRAM_BASE, offset, pattern); 

 

while(1) 

printf("Hello from Nios II 2!\n"); 

}  

 

 

 

 

 

I use the occasional printf statements to check how the program is running. The problem that I am having is as follows. When I run the above code on Nios Processor it starts to increment the offset and then starts printing garbage in the form of "yyyyyyyy..........". I looked into the code a bit in details and found that the offset is not incrementing after a certain value. I think I am making some fundamental mistake. Any help would be highly appreciated. 

Thanks in advance, 

D
0 Kudos
Altera_Forum
Honored Contributor II
678 Views

It could be that the SRAM write operation is failing and then preventing the rest of your program to execute (inc counter variables etc). 

 

Try removing/commenting the SRAM commands leaving the basic loop structures and printf commands in place. Re-run your software and make sure that the printf statements are executing correctly and debugging to your JTAG UART (I assume this is your printf device). 

 

The SRAM controller component in SOPC builder - is this the one included with the University Program IP cores or default Altera-provided component?
0 Kudos
Altera_Forum
Honored Contributor II
678 Views

Hi, 

Thanks for your reply. The program works perfectly if I donot communicate with the memory. The printf statements work fine. Its just when I try to access the memory the problem occurs. Anyways, I have solved the problem for now. I wrote my own memory controller and it communicates with the NIOS processor. But still, would like to know if anyone else faced similar problem or is it just my design that has this problem. 

Thanks again, 

Dipanjan
0 Kudos
Altera_Forum
Honored Contributor II
678 Views

I haven't experienced this problem before. Have successfully used the SRAM IP core provided with the University Program...however, there could be a hundred reasons why it didn't work. Writing it yourself probably works out better in the end - at least you know exactly what is going on! :)

0 Kudos
Reply