--- Quote Start ---
Either you didn't correctly configure the NIOS to boot from that RAM (reset/exception vector memory locations), or the software in the RAM is buggy.
Double check your Qsys NIOS parameters.
Check your Quartus reports to see that the RAM is correctly initialized from the .hex you thought it should be.
After the system boots, look at the RAM and see if the contents match expected.
--- Quote End ---
The reset/exception vector memory locations are ok. The processor vectors are pointing to the on-chip memory.
I noticed that the Eclipse GUI apparently had some bugs while preparing the *.hex memory initialization file. However, I used the command line to craft my own initialization as:
elf2hex --input=terrazas.elf --width=32 --base=0x10000 --end=0x19fff --record=4 --little-endian-mem --output=terrazas.hex
I got a *.hex file that looks like this when you open it in notepad:
:020000020000FC
:040000000040007448
:0400010008408B1414
:040002000800683A50
:0400030000000000F9
:0400040000000000F8
:0400050000000000F7
:0400060000000000F6
:0400070000000000F5
...
after this there are no warnings in the Quartus re-compilation
Finally, I am still not able to boot the processor. Any ideas of why is this going on?
Just to make it more clear, I want to be able that when I download the *.sof file to the FPGA, the processor should boot by itself (without me having to manually download the software from Eclipse)
Honored Contributor
