Struggling with boot from initialized onchip RAM

[Altera_Forum]

Greetings fellow Alterians! 

 I am using Quartus II 9.1 SP2, Cyclone III (16K) and EPCS16. My development board works fine and I can download and run software on my NIOS II via USB Blaster with no trouble. I have not gotten around to programing the EPCS yet.  I have been running around in circles trying to do something that I had originally thought would be pretty straight forward. I want to boot my NIOS II from an on-chip RAM that is initialized from a HEX file.  The crux of the problem appears to be that I cannot get the ".text" linker section to be within the "reset" linker region in the BSP editor. I have found several references that say that this must be done in order to boot in this way, including page 4-40 of the "Nios II Software Build Tools document" in a section called "Run from Initialized Memory Configuration". The last sentence says "The default Tcl script chooses this configuration when the reset and .text memory are the same.", but no where can I find any instructions on how to actually make this happen.  According to BPS editor, the "reset" region can only be 32 bytes large, which is not enough to hold my application. Making it larger results in a hard error in the BSP Editor. I tried bypassing the editor and configuring settings.bsp directly, which resulted in a compile error due to the region being too small for my application.  I am generating a HEX file out of the NIOS II software build environment (Eclipse) for my application and using it as the initialization file for the on-chip RAM. I'm generating this using the "mem_init_install" make target.  I am obviously missing something here, and the documentation is clear as mud on how to do this. Any insights from more experienced NIOS II developers would be much appreciated.  LH

[Altera_Forum]

If you only have one block of RAM available, the default linker setup should be okay. You can press the "Restore Defaults" buttons in both the Linker Memory Regions and then the Linker Section Mappings area to get back to the defaults. 

 You don't need to get the .text section into the "reset" region. Instead you need both .entry and .text to be in the same memory device.  One common problem when trying to run from initialized RAM is not setting the hal.linker.allow_code_at_reset option in the advanced settings.

[Altera_Forum]

1. Point your Reset Address at your onchip memory. 

2. Compile your code. 3. If it's too large, optimize it.  - Use alt_io stuff, small C Library, reduced device drivers, etc. 4. Create your memory HEX file.  - Know that you "may" have to manually move it into the root of your QII project. 5. Recompile your QII design.  - If you're lucky and all you've changed is the HEX memory initialization file, this step should be quick. 6. Program your FPGA. 7. Open a nios2-terminal and you should see proper output.  Regards,  slacker

[Altera_Forum]

Thank you for giving me the clue I needed to find the problem. My BSP was set to connect STDERR, STDOUT and STDIN to my JTAG-UART. This was causing my program to hang right from the start with no terminal attached to it. I set all of these BSP values to "None" and my "booting" problem went away. 

 I now have the whole system auto-booting out of an EPCS16 also, which is even better.  I appreciate your fast response to my problem!  LH

[Altera_Forum]

I was able to compile Nios code into a hex file that I then compiled into the *.sof image. 

 On power-up I had no problems with the Nios code running, however after a reset the Nios code would fail to run properly. It appeared to die after a few instructions.  I did end up fixing my problem by starting my Nios project/BSP from the "Hello World Small" option. I believe this option configures the BSP in a way that allowed me to reset the SOPC core with no problems.