Forum Discussion

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

Problem with SDRAM

Hello Folks,

i really have a problem with my Nios running on external SDRAM...

I try to get my own bord running and the code has to run from SDRAM.

I know the problem with the phase shift and have now running a system with 82 MHz and 120° Phase shift.

I used the MemoryTest - Project which comes with Nios II IDE und made it smaller so that it fit into my OnChip-RAM.

The Memory Test always runs through without any failures. SDRAM is there and working.

Then i try to run a Hello World on SDRAM.

The only configuration that at least starts debugging is the "Small Hello World" in Release bild.

The normal "Hello World" (release and debug build) i cant even start to debug as it doesnt find main.

The "Small Hello World" in debug build has the same problem.

Small version in Release Bild at least starts - but makes nonsense with the "Hello from Nios..." - String and pritty fast just hangs without any outputs...

I'm really frustrated already - anybody able to help ?!

I put my Project online as i frear (hope) that the problem comes from some adjustments within Quartus or Nios IDE...

I use Quartus 9.1sp2 and Nios IDE 9.1sp2

10 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi

    If you are not driving the SDRAM_CLK pin it gives wrong outputs

    you can use a PLL and generate a seperate clock and drive the sdram clock

    regards

    M Kalyansrinivas
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Are you sure you have all the interupt and exception vectors pointing to the correct places.

    It you run under gdb, the code should stop at the entry point, and you should be able to single step (the asm if necessary). But that will fail if the vectors aren't right.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I am using two clocks, generated with PLL. Both are there - measured them with oszi....

    Reset and exception vector point both to sdram.

    Interrupts - i have only the interrupt from the JTAG to program and debug. And in Hello World i dont use any other interrupts...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    If the jtag code download verifies ok (also check the sizes and addresses) them maybe you've forgotten to give the instruction master access to the sdram!

    Also verify that the sopc generate - quartos build - fpga download sequence is working properly after your sopc updates.

    The ide should force you to regenerate the BSP, then clean + compile everything.

    The ide 'run' is then likely to object to the version of the fpga image, it seems to cache the fpga version and needs manual prodding.

    I also found it seemed to run the old code (from sdram) then download and run the new version.

    I couldn't find a way of getting the ide to just do a sopc reset, code download, and execute. Not without it running make and asking questions about how you wnt to run the program (again).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I had those problems also at the beginning ;)

    but now i go the process

    sopc builder generate

    close sopc builder

    quartus than marks an update on nios and ask for updating (what i do)

    then i compile the quartus project

    switch zu nios ide

    start a build

    nios ide rebuilds bsp, then project

    then i debug / run that stuff...

    and in some cases i could verify that that an update on the sopc was correctly builded and downloaded...

    instruction master has acess to sdram... (and to onchip ram and jtag module)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Haqim,

    Does the system you're using to run the Memory Test example include a DMA? If not, then you are not fully testing your memory. The Nios II's instruction master will behave much more like a DMA when it comes to instruction fetches and puts much more stress on the interface timing than the data master.

    There also was an example on the Wiki that automagically chose the "best" SDRAM phase offset (should be in ns/ps, _not_ degrees...right?).

    Cheers,

    -slacker
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    If seen that example in the Wiki...

    Really nice hint on that, slacker. Problem is - i have way to small EP2C8...

    I tried to get DMA Test running, but it is just to big...

    Dont get it in my device ...

    I guess i do clock shifting manually and hope for a special time, where hello world runs on sdram... will take a while but dont see another way.

    If that doesnt work - i guess my pcb then is to bad ...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I'd have thought that data cache line reads and instruction cache line reads would look much the same to the SDRAM module.

    One thing you might manage is to put most of your test code into internal memory (which seems to work), then copy (or link) a small function into SDRAM. See what happens when you try to run that and/or (asm) single step into the sdram function.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Working !!!

    Great Thanks!

    I shifted sdram clock (82 MHz) from 0 to 12 ns.

    0 to 2 ns - verify of download failed

    3 to 6 ns - verify works, but debug mode doesnt find main (as descriped above)

    7 to 11 ns - verify works and debug mode finds main, HelloWorld is running

    i now use 9 ns delay :)

    thx again!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    You might be better specifing a -ve clock shift.

    It might be more resilient to changes in the system speed.

    On the cyclone III dev board I've been playing with the ssram clock is at -3.3ns. I think this value works for both 100MHz and 50MHz.

    That looks very similar to your +9ms at 82MHz.

    (The setup from altera was running at 100MHz, but I was having problems with shift instructions generating incorrect answers after I included some (possibly too slow) combinatorial custom instructions. It all worked at 50MHz with just the pll divisors changed.)