Problem with downloading of a NIOS II program

I'm not sure, but probably the problem comes from memory issues.

Here below - the system composition in qsys.

Note, that on-chip memory size is 20k (red cadre).

Memory base address is 0x8000 and the base address of one of the components (i.e. sysid) is 0x11048.

Subtracting 0x8000 from 0x11048 gives more than 20k.

If this is the issue, why it was not signaled when I generated system in qsys.

Regards.

https://www.alteraforum.com/forum/attachment.php?attachmentid=13330

I've created another application and have tried to download it to ma board.

The same result - problem occurred. downloading elf process failed.

And no any other hints/suggestions for workaround !

Is it a known problem ... or there is something wrong with settings in my hardware ?

Thanks.

Hi,

The start address is 0x8000 and end address is 0xCFFF which results in 20K memory thus I don't think there is anything to do with memory.

Another observation - absence of the memory driver in the board support package (please, see the screenshot below). Is it normal ?

https://www.alteraforum.com/forum/attachment.php?attachmentid=13352

Here below - the message in NIOS console after downloading fails.

Well ... there are 2 accompanying files generated while project is built: {proj_name}.map and {proj_name}.objdump.

Can I check some sections in this files that could me give a hint that something is wrong ?

Thanks.

https://www.alteraforum.com/forum/attachment.php?attachmentid=13353

I've found a workaround for a case, similar to mine, on Altera site ... at least, the console messages are similar (screenshot below)

I doubts that the hint can be applied to my case - in my case the program isn't downloaded

https://www.alteraforum.com/forum/attachment.php?attachmentid=13354

Problem resolved !

I modified system composition ... in this new working version I included pll, that generated new clock 143mhz for all for other blocks.

Before all blocks were clocked by external clock of 50mhz.

Apparently the role of pll is crucial. It would be nice to find some source (e.g. book, article) that treats such issues.

https://www.alteraforum.com/forum/attachment.php?attachmentid=13359

However while compiling this new system, another issue wondered me. Here is the extract from compiling report:

Warning: RST port on the PLL is not properly connected on instance nios_led:u0|nios_led_pll:pll|altera_pll:altera_pll_i|general[0].gpll.

The reset port on the PLL should be connected. If the PLL loses lock for any reason, you might need to manually reset the PLL in order to re-establish lock to the reference clock.

Quite strange, because as we can state from the Qsys screenshot, the signal reset of the pll block is connected to the clk_reset of the clk block.

Thanks.

Problem resolved.

I've modified the qsys system. After adding of the pll block and applying of the pll-generated clock (143 MHz) instead of external clock 50MHz, the nios ii code is downloaded and system works correctly.

Apparently the pll block plays a fundamental role in the system construction. I wonder if exists some document that treats this issue.

http://www.alteraforum.com/forum/attachment.php?attachmentid=13360&stc=1

The only issue remains incomprehensible. Here is extract of the design compilation report.

Warning: RST port on the PLL is not properly connected on instance nios_led:u0|nios_led_pll:pll|altera_pll:altera_pll_i|general[0].gpll.

The reset port on the PLL should be connected. If the PLL loses lock for any reason, you might need to manually reset the PLL in order to re-establish lock to the reference clock.

After all, as one can state from qsys screenshot, the reset signal of the pll block is connected to the clk_reset of the clk block.

Thanks in advance.

The Pll is not necessary in a Nios design. It's possible that your previous design didn't have timing constraints set up properly, and that using the pll somehow helped a bit the fitter, but I'm just speculating.

As for the warning, I'm like you I don't know. It looks like it's connected fine.

Indeed, I've just tried another design, that uses SDRAM memory (instead of on-chip memory) and the issue repeated.

Here is Qsys screenshot of this design:

https://www.alteraforum.com/forum/attachment.php?attachmentid=13367

Concerning timing constraints, compilation report didn't reveal any violation. Here they are:

create_clock -name clk -period 20 [get_ports clk]

create_clock -name {altera_reserved_tck} -period 40 {altera_reserved_tck}

set_input_delay -clock altera_reserved_tck -clock_fall 3 [get_ports altera_reserved_tdi]

set_input_delay -clock altera_reserved_tck -clock_fall 3 [get_ports altera_reserved_tms]

set_output_delay -clock altera_reserved_tck 3 [get_ports altera_reserved_tdo]

derive_clock_uncertainty

set_false_path -from [get_ports sw*]

set_false_path -from [get_ports key*]

set_false_path -from [get_ports sdram_dq*]

set_false_path -from * -to [get_ports led*]

set_false_path -from * -to [get_ports hex*]

set_false_path -from * -to [get_ports sdram*]

So, apparently, the issue with failed nios ii downloading is quite recurrent, and there is no any reliable remedy against it.

Am I right ?