Forum Discussion

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

A Newbie's struggle

I am sure the answer is simple but, I am running out of time...

I am running Quartus II V4.2 with Nios II V1.1. My proprietary target

system is based on the Cyclone EP1C2Q240C7, an EPCS chip "socket" (no

epcs chip installed) and one Micro MT48LC4M32B2-7 SDRAM. The Nios II/f

cpu is configured with 18KB of internal RAM. I can run "Hello World"

with added comprehensive SDRAM memory tests just fine if everything is in

onchip_memory_0. I cannot re-locate the .text, .rwdata and .rodata to

SDRAM and have a simple "Hello World" run at all - the debugger does

not start. I have tried setting the exception address to onchip_memory_0

and sdram_0 with no success. The reset address is always the

epcs_controller. Is the downloader able to start the user code in SDRAM?

What am I doing wrong? http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/sad.gif

5 Replies

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

    You have an EPCS controller but no EPCS device populated? When the system is set to boot from the EPCS controller then the bootloader within the controller starts copying the user region of the EPCS device (which you don&#39;t have) to the target (you want SDRAM).

    As for whether the downloader (Nios II IDE) can run code out of SDRAM, that&#39;s how all the Nios II reference boards run code when the IDE downloads to them.

    To verify, if you run your code out of on-chip memory you are able to access SDRAM properly? My other question is, why do you have an EPCS controller if you don&#39;t populate the EPCS device?

    I would have the exception address in SDRAM, and the reset address...... doesn&#39;t matter right now since you are trying to download via the Nios II IDE. I would probably stick the reset location in SDRAM right now because you are pointing it at a bootloader current and that may be causing you problems (I don&#39;t know why though).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    The EPCS device is mounted on a custom card that fits into a SD memory card holder mounted on the board. Thus, we can (hopefully) allow customers to update both hardware and software by replacing the one card in the field. The EPCS card makes no difference whether installed or not.

    The SDRAM test consists of walking bit tests, byte (DQMn) tests, long int address test (with prime number addend), fill zero test, fill ff test.... all that I have ever used in the past and then some. I&#39;ve tried playing with the PLL phase, but I can&#39;t make it fail. Clocking at half speed did not fail either, but did not help. I speculate that perhaps a longer reset delay (PLL stability?) might help.

    I do not have this problem with the SDK board. Perhaps the boot loader expects something in the EPCS flash when downloading to SDRAM? The puzzle is why internal RAM succeeds while external SDRAM fails. Perhaps the Nios II IDE expects flash to accompany SDRAM. Is the source for the boot loader provided?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    > Is the source for the boot loader provided?

    {INSTALLDIR}\altera\kits\nios2\components\altera_nios2\sdk\src\boot_loader_sources\boot_loader.S

    Regards,

    --Scott
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Hi ILJ,

    > The SDRAM test consists of walking bit tests, byte (DQMn) tests,

    > long int address test (with prime number addend), fill zero test, fill ff test....

    The II/f has a a data cache & it&#39;s always in write-back mode ... so you

    must invalidate the memory regions prior to doing your memory read/compare.

    Depending on how you designed your tests, it&#39;s possible that your tests pass

    because you always hit the cache & never actually read the SDRAM.

    I&#39;ve had debugger trouble when my reset address is in faulty SDRAM ... usually

    when I didn&#39;t have my PLL phase shift set properly.

    Regards,

    --Scott
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Scott

    Thanks for the path to the boot loader!

    The SDRAM tests were performed using the bit 31 cache bypass - in any event, the address test writes the full 16MB with unique values before reading it back for verification.

    From your experience, I suspect a hardware problem with SDRAM burst access not covered by my tests. From other postings here, I gather that the Nios II does not achieve back-to-back reads on its data bus, but does on its instruction bus. My tests would not detect this.

    I believe that the DMA is latency aware. Perhaps it would be a sufficiently challenging test to catch problems. I&#39;ll try.