Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.

Creating a hex-file

Altera_Forum
Honored Contributor I
1,749 Views

It cannot be that hard: 

I have a nios2 project (including onchip_ram with "Enable non-default initialization file" checked) that can be compiled to an elf-file. 

But i don't get any hex-file when i compile my project. 

 

I have been looking up and down in my nios-ide, have scanned the altera forums and have been questioning google for several hours. 

I have found serveral hints what to do but for some strange reason nothing really works. 

 

Hint 1: mem_init_install, mem_init.mk 

In my bsp i find the file mem_init.mk. But i really don't know what to do with it to get a hex-file. 

In nios ide i can do "Make targets\Create..." an manually add "mem_init_install". 

But afterwards when i try to invoke it by "Make targets\Build..." i get this error "make: *** No rule to make target 'mem_init_install' ". 

 

Hint 2: elf2hex 

When i use elf2hex 

(java -jar elf2hex.jar --input=Project.elf --width=32 --base=0x4000 --end=0x77FF) (base and end address come from my onchip_ram in the sopc-builder) 

i really get a hex-file.  

But when i now try to update the memory initialization files in quartus2 

i get this warning "Warning: Width of data items in "onchip_ram.hex" is greater than the memory width. Wrapping data items to subsequent addresses." 

So the hex-file isn't ok. Changing the parameter width to "--width=4" in hope to create a hex-file that looks like the default "onchip_ram.hex" will only produce an error "Width: 4 isn't a valid width". 

 

Any help will be greatly appreciated
0 Kudos
5 Replies
Altera_Forum
Honored Contributor I
300 Views

You could try "--width=8" for byte addressing, the width parameter changes the data width in the file. Not sure if this will help.

Altera_Forum
Honored Contributor I
300 Views

My solution: this batch-file 

 

@echo off 

 

if exist Project.hex del Project.hex 

 

set BIN_PATH="C:\altera\91\nios2eds\bin

 

java -jar %BIN_PATH%\elf2hex.jar --input=Project.elf --width=32 --base=0x4000 --end=0x77FF --record=4  

 

copy /Y Project.hex ..\..\onchip_ram.hex 

 

pause
Altera_Forum
Honored Contributor I
300 Views

Shouldn't the Eclipse tools be able to generate this automatically with just a  

click of a button/check_box? 

 

I have the same issue and would rather not create additional scripts unless necessary. 

 

Isn't all the information elf2hex needs passed with the SOPC system? 

 

In the worst case I can add a line to some edit box in the NIOS II eclipse project  

properties dialog. 

 

Or specifically what is the Altera recommended/approved method for performing 

this seemingly very common task. 

 

Thoughts? 

 

Thanks, 

 

Cos
Altera_Forum
Honored Contributor I
300 Views

This used to work, give it a try: 

1) Go to your project explorer, right-click on your project. 

2) select make targets -> build 

3) in the pop-up window, choose mem_init_generate then click build 

4) under your project folder, you will find mem_init subfolder 

5) look inside to see if there is anything useful (should have hex file and qip file for Quartus) 

 

benc
Altera_Forum
Honored Contributor I
300 Views

I had the exact same issue. I noticed 3 things: 

 

1. The project would still run correctly even though Quartus gave me the warning about the .hex files. 

 

2. The SBT would only create a .hex file that was being used by Quartus if I first ran the project "as modelsim". Then the SBT would build me a new .hex file, but not if I simply built the project. Through my own research I found out that the command "make mem_init_generate" in the NIOS console would build new .hex files after I made changes to the C code.  

 

3. For some reason multiple .hex files were created in various folders, and the one in the "mem_init" folder was the one being used by Quartus and not being updated by rebuilding the project. There were other .hex files in another folder that were being updated, but I can't remember where they were off the top of my head. 

 

It seems to me that the tools should just auto regenerate a .hex file with every project rebuild, and store it in a place that Quartus already looks at, instead of me having to flounder around and make these changes and find a work around. Just a suggestion to Altera... :)
Reply