- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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, MichaelLink Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Anybody has an answer?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Which boot loader are you trying to use?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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??- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page