Verification fails

Hello,

I have let the time-limited Nios II run overnight. There is no problem as long as the processor is connected to the IDE tool, so called "tethered" mode. I no of no other limitation of the Nios II Opencore.

Of course, even with the full edition, there a host of communication problems that I have seen running Nios II that are either self-inflicted or systemic. I seem to get a steady dose of "freezes" from processor paused to verification fails to non-response on the Shell.

Usually I just reset my board and try again.

My two cents.

-Baycool

thanks baycool for your help,

but I still have problem to get my software working. Do I have to set an option somewhere to run the "tethered" mode?

I already tried to disable verification by setting the "no-verify" option for the nios2-gdb-server. The effect is, that I dont get the verification failure but the sytem does not run, i.e. there is no response to IDE from the processor.

So, which furthermore options to I have?

When using an OCP core, you should get a popup window when programming the FPGA (in Quartus II). If you close this window, the OCP core (Nios, Megacore, whatever) will stop functioning. That's what "tethered" means!

Hopefully, that explains it.

- slacker

--- Quote Start ---

originally posted by rj043@Aug 29 2005, 09:52 AM

dear all,

i have problems running a simple "hello world" application on a time-limited design! i have to set up some computers at our pc-lab with the altera-software (quartusii 5.0 sp1, nios ide). to check the installation i've created a simple system, containing a nios2-cpu for our up3-education-kit. the system is created as time-limited-design and an information tells me, that the sram-object contains the time-limited megafunction that supports the opencore plus feature (i.e. the nios2 processor).

when i create and compile my simple "hello world"-programm everything looks fine, but during download, verification fails!

to make things worse: when i use my office-pc, which has a valid license for the nios processor, the system is (of course) not time limited and the software runs (after recompilation) without any problems!!!

so my questions are:

1. could it be, that the time-limited megafunction in the sram object interferes the process of verification?

2. are there restrictions for time-limited designs i did not notice?

3. is there a known bug?

--- Quote End ---

Did you create a new design? if so chk your pin assignments , chk the assignements for the component that is present at the address at which verification fails.

If not , what is your stdout , stdin, is it configured to be jtag ? , chk @ properties -> system library

also as slacker says do not close the OCP popup as that would assert the reset signal.

hope this helps

Just my one cent

regards

Pavan

Thanks to everyone for the help provided!

I now think this is a board-specific problem. I've checked every assignment twice and couldn't find a mistake! The problem only occurs when the sdram-memory is accessed! After I moved all memory sections (.text, .rwdata, etc.) to the sram-memory, I could run my programm. Furthermore tests with variables explicit stored in the sdram indicate a read/write-error. Take a look at the following lines:

int my_ints[5] __attribute__ ((section (".sdram_0")));

//sdram_0 base address is 0x1000000

...

int x,y;

for (x=0; x<5; x++)

{

my_ints[x] = x + 10;

}

for (y=0; y<5; y++)

{

printf("my_int[%d] at addr %x = %d \n",y,&my_ints[y],my_ints[y]);

}

and the output on the IDE-terminal window:

my_int[0] at addr 1000000 = 57599

my_int[1] at addr 1000004 = 1090490623

my_int[2] at addr 1000008 = 16716031

my_int[3] at addr 100000c = 16716031

my_int[4] at addr 1000010 = 1090490623

Maybe I should ask the manufacturer of the board, because when the design is compiled with a full license the output shows the expected values 10 to 14. By the way, I use a UP3-1C12 Education Kit provided by SLS Corp. ...

Hi all,

after correspondence with SLS Corp., the manufacturer of the UP3-1C12 education kit, the guys of the support team found out that there was an error in the sdram-timing. They correct all files and documents as soon as possible!

However, thanks to everyone for providing help here.