Problem booting program from EPCS flash and running from SRAM

[Altera_Forum]

Hardware and software tools: 

NIOS II IDE 10.1 ("Legacy") Quartus II 10.1 Device:Arria II GX - EP2AGX260FF35I5N  I am using software tools and hardware as described and a custom board.The problem as described in the title keeps popping up frequently in this forum so it might be a good idea to post the solution (step by step) in "Sticky" messages.Anyhow,i am facing the following problem - I have the FPGA and software tools and i also possess EPCS128 flash and 8 MB SRAM.I want to boot the Nios II program from EPCS and run in 8 MB SRAM.At this point i am able to run the program only in debug mode.In order to solve the issue I have tried the following solutions: http://alteraforums.net/forum/showthread.php?t=20623 --->I have reached the point when i created the joint (concatinated) hw+sw bin file and i have no idea what to do next (I saw that this is impossible to burn that file to flash using the console programmer ,maybe some conversion is required?) http://www.altera.com/support/kdb/solutions/rd12092009_471.html -->Trying to create .jic file and then burn that file using Quartus programmer.I have succeeded in doing this ,but the program still won't run after power-off and power-on,meaning it has not been programmed properly.Maybe the problem lies in the fact that the *.elf file used was from "Debug" directory and not "Release" (For some reason,the option of 'Release' has disappeared from IDE and i am not able to find that option anywhere). Any help would be appresciated Thank You very much,  Michael

[Altera_Forum]

Anybody has an answer?

[Altera_Forum]

The "app_image.bin" file generated on the first link you give is the very exactly image of the data flash. 

 you can try this, it could work :  nios2-elf-objcopy -I binary -O ihex app_image.bin app_image.hex  and then program it with serial flash loader...   [edit] I remove what I have write about the second link... it was wrong  :oops:

[Altera_Forum]

Which boot loader are you trying to use?

[Altera_Forum]

Here is the script I use to load up an EPCS with a FW/SW pair. The <EPCS BASE> should be the hex address of your EPCS controller component in SOPC Builder. (i.e. 0x04020000) Let me know if this helps. (as I can't send you a private message yet - too few posts:mad:) 

 #generate flash image for firmware <fw1> "$SOPC_KIT_NIOS2/bin/sof2flash" --epcs --input="<fw1>.sof" --output="<fw1>.flash" # program <fw1> firmware into flash memory "$SOPC_KIT_NIOS2/bin/nios2-flash-programmer" --epcs --base=<EPCS BASE> --cable='USB-Blaster ' --instance=0 "<fw1>.flash" # generate flash image for <fw1> software <sw1> "$SOPC_KIT_NIOS2/bin/elf2flash" --epcs --after="<fw1>.flash" --input="<sw1>" --output="<sw1>.flash" # program <sw2> into flash memory "$SOPC_KIT_NIOS2/bin/nios2-flash-programmer" --epcs --base=<EPCS BASE> --cable='USB-Blaster ' --instance=0 "<sw1>.flash"

[Altera_Forum]

i have tried this method already(and the gui flash programmer method,which is almost identical),still without success.I guess the problem is either in sopc builder configuration or in the board itself

[Altera_Forum]

In SOPC, what are your reset and exception vectors in the NIOS pointing to? 

 My NIOS values are set to: Reset - EPCS Controller Exception - External RAM  (I am assuming you have an EPCS controller block in your sopc project, it is required (normally) for the processor to boot from the EPCS)

[Altera_Forum]

yes,i have checked about thousand times. 

Now i have set up an internal small RAM inside the fpga-the program boots from epcs and runs inside the on-chip RAM,so i guess the problem is in the access to external RAM

[Altera_Forum]

I have the same problem. If I link my program to the SRAM, it doesn't boot, but if I link to the Onchip_memory, without change any other parameter or the script, it boots! 

 I've checked what is written in the SRAM after boot, and it's not the right code, I don't no why! At the first direcction of the SRAm it should be:  14008200 33000010 04F8BF10 16FDBF00  However it's:  140020A8 33002872 04F89739 16FD581E  It's like it only writes the 16 first bits of every 32bits. Connections are right, because if I run it with Eclipse, it runs correctly! What's happening??

[Altera_Forum]

Yeap,the same exact problem here too.The weird thing is that i am able to run the program in the ram (or debug) (using the ide).With oscilloscope i am able to see data changing on address and data pins,but i don't see any data running on control pins of the ram (clk,ce,bwe,etc.) not in debug/run mode nor in regular mode

[Altera_Forum]

Following the advice by altera support i have performed a memory test for my external SSRAM-this was the output : 

Testing RAM from 0x0 to 0x1FFFFF  -Data bus test passed  -Address bus test failed at address 0x80000

[Altera_Forum]

Check your connections to the SRAM address pins. Have a look at the board schematics and verify that they are connected at the same FPGA pins that you have declared in the Quartus project.

[Altera_Forum]

the connections are fine.The memory just goes from 0x0 and 0x7ffff.After setting THOSE boundaries ,memory test goes ok,though sopc builder address range is between 0x0 and 0xfffff.Nothing i can do about that ,because that seems to be default.I use Cypress-like SRAM (ISSTIS61VPS51236A 512x36)- It has same pinout as of cypress.I have noticed this problem keeps popping up over and over again along the years(i ran into posts dating back to 2005)

[Altera_Forum]

you should edit your component so that it has the correct span. If you don't you risk having some parts of your application mapped to non existing parts of memory.

[Altera_Forum]

I have edited it as much as i can :). I have set memory size to the minimum-which is 1 MB.Deeper editing than that requires editing SOPC generated files - i am not sure i need to do that.I am using standard memory,512Kx36.I am sure this address span is not an issue.

[Altera_Forum]

Oh I didn't see the memory size... The span for a 2Mb memory is 0-0x1fffff, so you definitely have a problem with your address lines if the memory test software finds a problem at 0x80000. Be especially careful with the lew bits of the address bus. A0 from the chip point of view is in fact A2 as seen by SOPC builder on a tristate bus.

[Altera_Forum]

Did that change beforehand,that didn't help either.Maybe I should put 'v' on shared signals in avalon tri-state-when i put v on everything,ram didn't work at all

[Altera_Forum]

Maybe got to the root of the problem.This post: 

http://www.alteraforum.com/forum/showthread.php?t=21763 shads a light on the problem.Probable cause of the problem being that the boot loader code adapted to 8-bit external RAM.I,on the other hand possess "modern" RAM of 32-bit.So the boot loader needs to be adapted.Any chance for anybody to have the "adapted" code,or link to some official adapt by altera?

[Altera_Forum]

Got this problem resolved on my own,NOT thanks to any altera technical support (FAE/mySupport).After examining the schematics connection in Nios development board of the same Cypress type memory,i got suspicious.I could see that the connection isn't straightforward,i.e. address to address.After examining avalon bridge documentation:http://www.altera.com/literature/manual/mnl_avalon_spec.pdf i could see that for external device of 32-bit data width there is a different scheme of connection.The only thing that kept me from reaching the solution earlier is that i didn't connect ALL the pins and haven't set the memory size (2 MB) in SOPC properly.I should have probably got that from failing memory test at 0x80000.Anyhow it works now,and one important thing i have learned from this is to look closer at examples ,either from SOPC and also the schematics of evalution boards with similar hardware configuration. 

Good day all,  Michael