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++
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.
12437 Discussions

System Failure when Recompiling with mem_init files

Honored Contributor II

Hi all: 


I'm as novice user of NIOS II Eclipse, any comments on my problem would be much appreciated. 


I recently created a project, and verified the function of the system by: 

1) compile qsys and other hardware in Quartus II and download to target. 

2) create project and BSP in Eclipse and download to target using run as hardware command 


It all works fine, but then I try to create mem_init file from Eclipse to include as part of Quartus design so to eliminate the step to download from Eclipse to target. 


It compiles successfully in Quartus but fails on target. 

when I go back to Eclipse, I finds that it detects a system ID timestamp mismatch. This same problem occurs when I remove the system ID component from qsys. (system ID mismatch although there is no system ID to check) 


I am using Quartus 11.0 and NIOS II for Eclipse 11.0 

I have done a similar project a while ago with the same v11.0 design software and similar process with no problem. 


Any advice welcomed. 


0 Kudos
2 Replies
Honored Contributor II

The only way I have been able to consistently create mem_init files has been using the "make mem_init_generate" command in the NIOS console. I'm using 11.0 also, and for some silly reason, building the project in eclipse doesn't update the mem_init folder that Quartus uses during compile. Randomly, clicking Run as -> Modelsim updates the files also.

Honored Contributor II

There was a bug in earlier versions of Quartus (or sime bit of the GUI) where, following a re-load of the fpga, it compared against a cached version of the fpga timestamp instead of reading it from the fpga. 

That may be still present, and might be confusing things. 

Some 'random' mouse clicks would cause it to re-read the timestamp value. 


In this cae careful inspection of the timestamp values showed that it had the new value for the code, but the old value for the fpga image.