Forum Discussion

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

EPCS controller booting trouble

Dear NIOS friends,

I am porting a system that was developed on a (custom board) with a EP1C6 to a new board revision with a EP2C8. Both are configured with an EPCS4 device and it worked very well on the 1C6 design that was compiled and programmed with Quartus / NIOS 5.0. To fully utilize the Cyclone II potential I made the move to 5.1 and this where the trouble starts. First of all the nios2-flash-programmer refused to program a device that gave back a device identification (my EPCS reported 0x202013) and the flash programmer reported that this device had no layout data and that it could not be used. It took me a few days of debugging (I thought it could be something in the hardware) before I figured out that the programming worked perfectly well with an old EPCS device (one that did not support the RDID command). So far so good, but it worried me a little. Any of you out there than ran into the same kind of trouble?

But more problems: I can now program every file I like, and the contents can be successfully verified. The configuration is loaded into the FPGA but apparently something goes wrong with the bootloader when main memory is set to SDRAM. The code starts up nicely when compiled for on-chip memory (I am sure the code is copied from EPCS, reset vector in the SOPC builder set to epcs_controller), but not for SDRAM. I know the SDRAM is working correctly, because I left the board running with memory checks overnight to be sure no problems are introduced there. Is the bootloader that comes with the NIOS kit smart enough to know where to copy the NIOS code? I noticed that the compiler is also generating an epcs_controller_boot_rom.flash in the Release folder in my project directory. Any thought how to check this? It worked fine with the 5.0 release and I am pretty sure I did the Board Description thing right... It's taking me more than a week now to get this running. Thanks.

4 Replies

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

    Hi Arjan,

    > The code starts up nicely when compiled for on-chip memory (I am sure the code is

    > copied from EPCS, reset vector in the SOPC builder set to epcs_controller), but not

    > for SDRAM.

    Just to be sure: you _always_ have your reset vector set to the epcs controller, but the

    problem occurs when you set .text, .data, etc. to SDRAM, yes?

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

    Scott, I made sure that the reset pointer in the SOPC builder _always_ points to the epcs_controller. And the problem occurs when I assign all segments to SDRAM. That's right.

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

    Hi Arjan,

    Assuming you're doing everything the same WRT to programming the epcs device and using on-chip v. sdram, I would still be suspicious of the sdram controller/device itself.

    Is there any chance your memory tests are missing failures. E.g. -- are you using a

    data cache, but forgetting to flush/invalidate before doing the read back?

    > Is the bootloader that comes with the NIOS kit smart enough to know where to

    > copy the NIOS code?

    Yes -- basically for each elf (output) section there's an address-length-data record

    that gets programmed into the epcs. The address/length is the VMA/size from the

    corresponding section in your elf file.

    It would be a good idea to check your elf file (via objdump) to make sure your

    sections are where they need to be and review jdhar's document.

    Regards,

    --Scott