Actual system ID not found on target at base address

Check if you possibly have a situation like the one I explained here in the second part of the message:

http://www.alteraforum.com/forum/showthread.php?t=37697

In any case, I suggest you add in the new design a blinking LED, a switching signal or anything else in order to make sure fpga has been correctly configured.

--- Quote Start ---

Check if you possibly have a situation like the one I explained here in the second part of the message:

http://www.alteraforum.com/forum/showthread.php?t=37697

In any case, I suggest you add in the new design a blinking LED, a switching signal or anything else in order to make sure fpga has been correctly configured.

--- Quote End ---

Thank you Cris72. I have seen your the other post as followed.

"

I often observed this behaviour in two situations:

The first one happens when I first load a design, then I load a different one without closing the previous Nios console window. Although this seems not to be your case, all I need to do here is closing the old window.

The second one is more subtle: it happens when I saved the previous design in a NV memory (epcs or whatever) for automatic boot upon power up. If you then load with jtag a newer design having the same base epcs address, the OLD Nios firmware would indeed boot from epcs and this could lead to the inconsistency error. The solution is making sure epcs is blank when you switch to a new design.

"

But i am sorry i have not understand what your say. Could you give me more explaination?

I have try lots of approach, for example to build a new Nios system after remove the legacy one, check the jic file, sof file and elf file is for one project. I also observe other solution posted in this forum. But there is no any good news.

First of all load your fpga design with jtag; at this stage don't use flash programmer, nor try to load it into epcs.

Then, make sure the expected configuration is working; as I suggested, I usually implement a free running counter with a LED connected to the MSB, but you can use any other method.

At this point you should read sys ID and timestamp with Eclipse tools. If they can't be found, then you probably have a flaw in your design: it could possibly be a problem with reset signal (unconnected or wrong polarity) or a missing clock.

Hi, Cris72

Thanks for your detailed guide and I find my trouble is rst signal. Faint, It is a low-level problem. Now i have work it out. Thanks again

IIRC At least some versions of quartos/sopc cache the system-id (rather than read it back) so compare the data from the 'elf' image with the wrong value.

There is a button lurking in the bowels of the pull-down lists to force a re-read.

I think this may happen when the processor has hibernated with Eclipse still running.

I have been able to sort it twice now, by re-starting Eclipse and the programmer.