Process for Embedding NIOS Code in .pof

[Altera_Forum]

I am having a problem getting my NIOS code to load into my configuration device.  

 i believe the real question here is how do i get the onchip_memory.hex file generated when i compile the nios code to embedded itself into the .pof file.  1. I am using active serial programming. 2. I do have the license so my .sof is not time limited. 3. I have for six months successfully been using the .sof files and JTAG programming to load and debug my C code and VHDL, but when I try to use the active serial approach to load my configuration device with a .pof image it doesn’t contain the NIOS C code.  4. I can successfully program the part, but it doesn't include the software portion of the image when I am complete. (I can get VHDL to twiddle LEDs but the C code doesn't seem to be there) 5. SOPC builder has "enable non-default initialization file" unchecked.   I am sure this is a very basic question, but I can't seem to find it on the forum. Thanks

[Altera_Forum]

Hi, 

 if you would like to have your Nios code in the programming file, you have to have a on chip rom (maybe a ram will work, too) and you have to check the "Enable non-default initialization file" option in your SOPC on chip rom module.  You have to make sure that the Nios II IDE creates a *.hex file named according to the field "User-created initialization file". If all your settings in SOPC are okay (reset vector, etc.) then it should work after you re-generated your SOPC system and recompiled your Quartus project. After recompilation of your Quartus project, the Nios program should be also in your *.sof file.  The basic steps are as follows:  1. Build your SOPC sytsem with onchip ROM and enable the "Enable non-default initialization file" option. 2. Generate your SOPC system. 3. Create a Nios II IDE project based on the just generated SOPC system. 4. Build your Nios II IDE project and make sure that the *.hex file according to your "User-created initialization file"-name was created. 5. Go back to SOPC and regenerate the system that now includes your *.hex. 6. Implement your SOPC sytsem in a Quartus project and compile this to get your *.sof and *.pof files.  This is the way I do it.  Maik

[praveenkumar]

Hello,

while combining the hex and sof files   there is an error commin in hex filr memory overlaps between address 0 and 8.

can u suggest where to store it in memory locations  of hex and sof files.

pls help me with thi

[Altera_Forum]

Thanks Maik for the detailed list. I have tried your steps several times with no luck! 

 Another thought I still have....Do I need to preform an update of my memory initiilization file?  From the Quartus Menu: Processing...Update Memory Initialization File

[Altera_Forum]

The way I have historically done it: 

 1 - Build your SoPC system. By default, your onchip memory will use a ".hex" file with the same name as the memory (e.g. "onchip_memory_0.hex"). 2 - Build your NIOS project in the IDE. Upon successful compilation, the IDE will produce the desired "onchip_memory_0.hex" (or whatever you named your memory component). However, my understanding is that this has changed somewhat in 9.1 and you have to do a little extra work. Let me know if you are using 9.1. 3 - Build your Quartus project. During the assembler stage, the "onchip_memory_0.hex" will automatically be used to initialize your RAM.  Now with regards to the "Update Memory Initialization File" menu item. Use this if: You have changed your software code. and you have NOT changed your SoPC system. and you have NOT changed the rest of your FPGA design.  Basically, running "Update Memory Initialization File" followed by running the assembler just updates your programming file with new RAM contents (containing your software code).  Jake

[Altera_Forum]

Thanks Jake, 

 When I compile from these steps I see the timestamp change on the .hex so I know it’s being modified. Of course then when I recompile from with Quartus my .sof and .pof timestamps change as well leading me to believe that my files are being updated with the NIOS code, but when I use the byteblaster on my DE0 development board I get NO code execution. The LEDs show that something is happening (hardware configuration) just no CPU functionality. As I mentioned in a previous post if I just run from the debugger everything works.   Am I doing something stupid like not building a release version of the NIOS code?  John

[Altera_Forum]

Look at your compilation report under: 

 Fitter -> Resource Section -> RAM Summary  You should get a table that lists each RAM block in the design. One of the columns indicates which MIF (or HEX) files is being used to initialize the memory. Verify that it is correct for your onchip memory.  You can also look at "Analysis & Synthesis" -> RAM Summary and see what it's showing for the MIF file.  Another thing to try is attaching to the existing target with the NIOS debugger rather than downloading the code and executing. Then, if the CPU is running, the debugger will just hook up to it at it's present location. You set this option in the run configuration dialog for your project in the IDE. We've seen various situations when for one reason or another, the code will run when download it but hang when you try to boot from it and run.  Jake

[Altera_Forum]

I see the onchip_memory.hex filename under Fitter -> Resource Section -> RAM Summary as you suggested, but how do I attach to target? 

 Thanks

[Altera_Forum]

What version of the tools are you using? 

You have to open the "Run Configuration" dialog for the software project you are working with.  From the IDE: Run->Debug...  Then click on the debugger tab. There is a panel entitled "Download and Reset". Under this panel, change the selection from "Download program to RAM" to "Attach to existing program on target (no download)."  Jake

[Altera_Forum]

version 

I am using the 9.0 Web Edition ...and I own a license for NIOS. Also I am on a Vista box and I am using the GUI versions of the tools for compiling. (I am command line challenged)   remote debug I tried to connect directly...that is I assume what you asked me to do... was to load the .sof (hardware) with Quartus and then use the NIOS IDE to debug the hardware with the debugger set to "attach to existing program on target (no download)" hoping that this would flush out some sort of connection problem. Result == the same as before. The LED digits are lit from loading the .sof, but inanimate or unaffected by the code that should be running.  Again when I load the .sof and then run the debugger using "download program to ram" the debugging and code works great. I just can't create a .pof that I can load into the EPCS via the AS programming mode.   other thoughts I am using the SDRAM core and the University Program SDCARD IP cores. These wouldn't interfere would they??? Is it possible that these need a time-limited version and the NIOS License prevents a time-limited build creating my scenario???  (It has always been unclear to me as to what falls under the description OpenCore Plus.) There is some sort of color code scheme (some are light green and some are grey), but are these all free to be included in designs? How do I know which ones need licensed?

[Altera_Forum]

It might be worth looking at the elf program that is generated to check that the code and data sections have the correct addresses for the internal memory blocks. The link script used by the IDE build rather assumes that your code+data is being loaded into a large memory area (eg the SDRAM) and code is added to copy the data into internal memory. 

 Look at the output of 'objdump -p' (and maybe 'objdump -h') to ensure that the physical and logical addresses are the one you need.