Forum Discussion

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

Problem debugging on a custom cyclone board

Hi:

This is just about getting us crazy. We have designed a custom board with a Cyclone chip for implementing a NIOS II processor, both the processor and the SDRAM seem to work ok (some implementation details are included below) but we can not debug or run any program we create using the NIOS II IDE, not even the simplest hello word sample. The debugger never stops, thougt we can suspend execution and place some hardware breackpoints for running step-by-step.

When paused, program execution is being done...............over the flash area!!!!, which in turn is erased/empty since we still haven't placed anything there yet.

We are using the same memory space configuration with one Altera NIOS development kit, Cyclone Edition, and in that board it works ok.

Program and data seem to be properly downloaded to the target as the console shows with the following messages:

----------------------------------------

Using cable "ByteBlasterII [LPT1]", device 1, instance 0x00

Pausing target processor: OK

Reading System ID at address 0x00811CB8: verified

Downloading 00811000 ( 0%)

Downloading 00811820 ( 0%)

Downloading 01000000 ( 1%)

Downloading 01010000 (95%)

Downloaded 68KB in 3.2s (21.2KB/s)

Leaving target processor paused

----------------------------------------

The custom board includes one EP1C6F256C8 cyclone chip, one 48LC4M32B2-7F SDRAM chip and one EPCS4 among other things (including a flash memory). The SDRAM has independent address and data buses from other peripherals and memories. We have implemented an internal ROM with the GERMS monitor (reset address points to this memory) and a 512 bytes internal RAM (exception address points to this memory). For the legacy SDK support, the internal ROM and RAM are declared as the program memory and data memory, respectively.

After power on (provided that the FPGA configuration is stored in the EPCS) the Cyclone device is properly configured and the GERMS monitor starts working as expected. Using one PC serial port we can communicate with the GERMS monitor on the board, using an external application (on the PC) and the GERMS monitor on the Cyclone we tested the SDRAM and it seems to be working fine (content is not lost, address and data lines seem to be properly connected).

Any kind of help or tip will be very welcome. Thanks a lot in advance...

10 Replies

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

    Hi VLorenzo,

    What frequency clock are u using for the processor and SDRAM? And what phase shift between CPU clock and SDRAM clock?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    But...a stupid question r u using "legacy SDK support" and NIos II IDE for the same design? I'm not sure they can be used together. See AN350 document.

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

    The clock frequency we are using is 50MHz, with phase shift of -72deg for the SDRAM clock.

    I've now recompiled without the Legacy SDK support to see....BUT SAME RESULTS!!!!!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    After this modification, where have u placed your reset and exception address in SOPC?and where program and data memory in system library in IDE?

    In our custom board we use the phase shift of -3.5 ns (the same used in EP1S10 development board)...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    We have the reset location pointing at internal ROM (0x00811000) and the exception address pointing at internal RAM (0x00811800 + 0x20).

    In the system library project, program and data memory (.ro, .rw, etc.) sections are pointing at SDRAM (0x01000000).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Try to set the reset address in SDRAM (or EPCS4) disabling Legacy SDK support. In your last configuration your reset is in ROM where is the GERMS that's for Legacy SDK...so a strange situation...

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

    We use the same memory space configuration with the Altera development kit, and it works...

    If I place the reset address pointing to the SDRAM........no one knows what the SDRAM will contain at CPU reset.

    Whay does one board work and the other not?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    After all of this headache, It's working!!!

    Thanks a lot Soin for your help!!

    The cause was the SDRAM PLL phase delay. Once set up to the value you said it all started to work.

    Thanks again.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Just for others to note:

    The reason SDRAM access worked with GERMS is that subtle memory timing problems will not reveal themselves as a result of the CPU data master accessing RAM -- the data master performs one read or write every once in a while, but not continuously. By contrast, instruction fetch (and cache fills) will exercise the SDRAM interface with a new word of data on each clock. If there is a subtle timing problem, such as setup/hold violations due to clock-phase-shifts, then these will be manifested when you try to run code from SDRAM, or do something like a DMA transfer.