Forum Discussion
Altera_Forum
Honored Contributor
14 years agorunning program in SRAM doesn't work
Hi all,
I am running my C program in NiosII and I need to print out the result on the console. There are a 512KB SRAM and an 8MB SDRAM on the board. The program works fine with the SDRAM. However when I changed all the program sections' specification to SRAM in the BSP Editor (in the Nios II SBT), the program can be downloaded to the board but it shows nothing on the NiosII Console. My program is 106KB so should be possible to run in SRAM. Anybody who can tell me possible reasons why it happens?24 Replies
- Altera_Forum
Honored Contributor
Did you remember to change the nios cpu's reset/exception vector?
These may need to correct even when loading from jtag. - Altera_Forum
Honored Contributor
hi dsl
Thank you for your reply. I changed the reset/exception vector to the SRAM but it still doesn't work... - Altera_Forum
Honored Contributor
Hi srhikari,
Did you get this working? I have exactly the same problem trying to run the software on SRAM. I even tried running it on the Cyclone III NEEK dev kit with the same results. It runs fine with SW running in SDRAM, but no Nios II Console output when using SSRAM. Yet another glitch in Qsys/Nios II. Please let us know if you find a solution, I will do the same. - Altera_Forum
Honored Contributor
sorry can't help you :(
it still doesn't work so i skipped it and run in SDRAM - Altera_Forum
Honored Contributor
did somebody make to run a program in sram?
- Altera_Forum
Honored Contributor
--- Quote Start --- did somebody make to run a program in sram? --- Quote End --- Yes, but there are lots of things to consider - proper pin connectivity, control signal polarity, Qsys configuration, Generic Tristate Controller configuration, timing closure, etc. This is a custom board, I presume? Can you provide a screen shot of your Qsys design? - Altera_Forum
Honored Contributor
Hi, do you have flash in ur qsys system? If yes, I suppose you are gonna have 2 generic tristate controllers, tristate bridge and a tristate pin sharer connecting together. In your top level design, pls check its connection. For 16 bit sram, u should ignore the first bit and so on. I encourage you to have a look on qsys handbook, Tristate chapter. Hope it helps.
- Altera_Forum
Honored Contributor
thank fheineman and caridee,
here you have a screem shot but i m using SOPC builder instead of Qsys (and Quartus II 11.0sp1 Web Edition (32-Bit)).can thAT generate any problem? My board is cyclone iv DE2-115. my project run from sdram but when i change linker region(BSP editor), reset vector and exception vector(SOPC) from sdram to sram, the file .elf cant be downloaded: "Hardware configuration' has encountered a problem. Downloading ELF Process failed" - Altera_Forum
Honored Contributor
--- Quote Start --- Hi, do you have flash in ur qsys system? If yes, I suppose you are gonna have 2 generic tristate controllers, tristate bridge and a tristate pin sharer connecting together. In your top level design, pls check its connection. For 16 bit sram, u should ignore the first bit and so on. I encourage you to have a look on qsys handbook, Tristate chapter. Hope it helps. --- Quote End --- PeFarina, It is a common practice to share address and data pins between SRAM and Flash memory to reduce the number of pins required in your FPGA design. If this is your case, you need to add a pin-sharer module in SOPC Builder. I'm more familiar with Qsys, but I imagine the configuration is similar. I attached a screen shot of my Qsys design to show how the pin sharer connects the SRAM and Flash. If you have separate address and data pins for your SRAM, then you don't need the pin sharer. - Altera_Forum
Honored Contributor
thank but i have separate address and data pins for my SRAM. i dont know what is wrong.