Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

Trouble Compiling SocKit DDR3 Example Code

I have been trying to get to the bottom of an issue for the last few days and have just figured out where the problem:

I have a project which uses the provided reference assignments and implements a NIOS II processor using the DDR3 RAM attached. The processor runs fine, until you get round to using the DDR3 RAM, at which point it falls over (restart, corrupted output in the nios console etc.).

Originally I thought it was something to do with timings, or pin settings - but apparently its not hardware.

So the SocKit development board comes with some supporting projects showing how to use some of the system, so I went to those to check where I went wrong. I ran both the RTL and NIOS II examples using the FPGA RAM - both worked fine (running from precompiled bitstreams and NIOS binaries). Hardware is not damaged :D

Next I recompiled the RTL demo from the Quartus project provided, again it worked. Yay.

Next I recompiled the NIOS example from the Quartus project provided, then went into eclipse created a new project (memtest) with BSP using the sopcinfo file. Run it and it fails. BUT if I use my bitstream with the example NIOS binary it works.

I also tried importing the project inside the example project folder - again it doesn't work.

Any ideas because I am losing my will to live over this! Why cant examples just work...

1 Reply

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Dear Colleague,

    I feel you pain.......

    I have not found a final solution to this issue, but I have now seen Nios executing code out of the DDR3 memory that is attached to the FPGA.

    I based my work on the sockit_ddr3_nios_test example that ships with the SoCKit.

    1) In the Nios-SBT, I "run-as-Nios-II HW", and after a lot of random messages the system reports that it failed to verify a memory location so downloading of the .elf failed.

    This leaves the Nios processor paused.

    2) However, if I go to Run Configurations and un-tick the "download .elf file" option, and run the "download-activity" once again, the Nios processor is released from its paused status, and starts to execute the .elf that was downloaded the first time around.

    Questions to resolve..

    1) How do I keep the screen open that shows the memory-space that fails to Verify? This is closed down by the SBT before I can grab any data off it. :(

    2) Setup the system to load the FPGA image and the Nios application from QSPI.

    Thus you might have a working system, that is being stalled by a failure to verify an obscure location in the DDR3....

    Hope this helps.

    NN