So, as title suggests, I have a NIOS system generated with SOPC and NIOSruns from Onchipmem RAM with memory init file my_fpga.hex. I generate the SOPC system. I build the NIOS code which generates my_fpga.elf I run from the NIOS console: elf2hex my_fpga.elf --width=32 --base=0x0 --end=0x32000 my_fpga.hex I build the FPGA which generates the .sof I create .jic with the .sof I program .jic into the EPCS device. No worky. :( All of the code was working by programming .sof and then using Eclipse to download the .elf. A few words on: elf2hex my_fpga.elf --width=32 --base=0x0 --end=0x32000 my_fpga.hex Width of Onchipmem RAM is 32 in SOPC Base address is 0x0 in SOPC. End address is 0x31FFF in SOPC (I should change 0x32000 to this I believe but Quartus build warning says it truncated anyhow so this should not be an issue). Anything obviously wrong here. Thanks in advance for any feedback, Cos
Where is your Reset Address In Nios II settings inside SOPC Builder?- It should be pointed at the onchip memory. There should be a more automated way to do this....in the old IDE this HEX file was always generated automagically. In the new(er) SBT-based flow, there should be Makefile targets to take care of this... In my experience, typing "make help" gives you a list of targets/options. Cheers, slacker
>>>Reset Address In Nios II settings inside SOPC Builder?Yup. This is set to 0x0 to correlate with base in which is same in SOPC for that mem: elf2hex my_fpga.elf --width=32 --base=0x0 --end=0x32000 my_fpga.hex Agree on the automated comment. Anything you see wrong with my documented process or other suggests? Thanks! C
So, done a bit more debugging with no success.I have included the onchip mem instantiation info from Quartus below. I have verified that the FPGA does in fact boot from the given .jic from power up as I can come in with Eclipse after and download and run the .elf code. So, problem must just be in the NIOS loading/running with the .sof/.jic used. I have fixed this: elf2hex my_fpga.elf --width=32 --base=0x0 --end=0x31FFF ../../my_fpga.hex Not sure if I am calling this correctly. There are a bunch of other options/flags for elf2hex. I am attaching the elf and output hex files. Does the hex look somewhat correct? I noticed all the bytes are pushed to the right side far column with 0x00's everywhere else. I have no idea how to debug this black box and could use a hand. Thx, Cos Info: Instantiated megafunction "my_fpga:my_fpga_inst|onchip_memory2_0:the_onchip_memory2_0|altsyncram:the_altsyncram" with the following parameter: Info: Parameter "byte_size" = "8" Info: Parameter "init_file" = "my_fpga.hex" Info: Parameter "lpm_type" = "altsyncram" Info: Parameter "maximum_depth" = "51200" Info: Parameter "numwords_a" = "51200" Info: Parameter "operation_mode" = "SINGLE_PORT" Info: Parameter "outdata_reg_a" = "UNREGISTERED" Info: Parameter "ram_block_type" = "AUTO" Info: Parameter "read_during_write_mode_mixed_ports" = "DONT_CARE" Info: Parameter "width_a" = "32" Info: Parameter "width_byteena_a" = "4" Info: Parameter "widthad_a" = "16"
The attached hex file contains all zero data which is obviously wrong.If you are used the Altera SBT tools to generate your make files, you should be able to just run "make mem_init_install" to automatically generate the appropriate hex file. I think the main problem with your manual attempt is specifying the wrong base address in your elf2hex command line. The code looks like it starts at 0x11000000 in you ELF file, not 0x0 which you specified in your elf2hex command line.
Makes sense.I just realized I had a bridge between NIOS and onchipmem. The mem is at 0x0 but the bridge is at [drum roll] 0x11000000. Long time since I worked on this. :oops: Like to know how you pulled the address 0x11000000 out of the elf. I will get that fixed. Lastly, is there a way to not have to build the whole FPGA whenever we just want to add different elf/hex NIOS code to the sof/jic? Thanks! Cos
--- Quote Start --- Like to know how you pulled the address 0x11000000 out of the elf. --- Quote End --- nios2-elf-objdump -D my_fpga.elf | less There are probably many other ways as well. Using the above method I could also see if the proper code was at the rest address. If the BSP is setup incorrectly, it is possible for the ELF to run correctly when downloaded via JTAG but to fail when executed straight from block RAM. --- Quote Start --- Lastly, is there a way to not have to build the whole FPGA whenever we just want to add different elf/hex NIOS code to the sof/jic? --- Quote End --- To update the SOF, do the following in Quaruts: 1. Processing -> Update Memory Initialization File 2. Processing -> Start -> Start Assembler