Forum Discussion

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

NIOS II Flash works but not on cold reboot

I am working on a Cyclone III board that is a custom layout and I am having issues getting it to work as it should from a cold reboot.

I have no issues in Quartus 10 compiling and programming via active serial or JTAG. The board works as it should from a reboot.

In NIOS II software I can flash the .elf file, and with the "Run from reset" option enabled but this only works when I program the firmware through JTAG, otherwise it will give me a Timestamp and ID error.

I also tried flashing the .elf and the .sof file with the "Run from reset" and it too worked just fine.

When I take power off of the board and restart it, it seems that the firmware is still running but nothing form NIOS II code is functioning. I have some indicator lights that tell me the firmware is working but I am not sure if this is from a previous active serial upload or the upload through the NIOS II software.

I have been trying to read all that I can and at this point I am going in circles. I am not sure what else to look into as possible causes of programming through NIOS II not working.

Any suggestions would be much appreciated.

6 Replies

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

    What's your flash device? epcs?

    Does Nios reset address match flash base address? Otherwise fpga will configure correctly but Nios won't boot. This seems to be your situation.

    It could also be a problem related to bootloader. While jtag automatically loads all memory sections, when you boot from flash the bootloader must take care of this. Do you use a single memory (sdram, onchip ram, ...) or do you have more devices? Any tightly coupled memory?

    Another error which could cause such a behavior is a mismatch between the fpga configuration you flashed and the one required by Nios firmware, but I guess you already checked this point.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hmmm... It really ought to be possibly to write a bootloaded for ECPS that loads from an elf image (using the program sections). The non-loadable sections can be removed (with objcopy or similar) to save space.

    Even post processing the elf file (using the program headers) so that a simpler loader could load multiple sections would do.

    The increase in the image size caused by adding the section info is probably less than the code needed to sort out the sections at run time.

    Unless things have changed since I used the default linker script, it is almost impossible to initialise multiple internal memory sections because the boot code tries to copy all the data into one of them first - and it wont fit.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    The flash device is an ECPS4 and I just use On Chip Memory for everything.

    You will have to excuse my ignorance, I am mostly a hardware guy and getting this deep into FPGA stuff is all new to me. I have been doing everything via the GUI so running things manually via command line is all foreign to me as well.

    How does one go about finding the reset address?

    Would this be in the linker script area of the BSP editor?

    As for the flash address would this be the address for the EPCS controller?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    How does one go about finding the reset address?

    Would this be in the linker script area of the BSP editor?

    --- Quote End ---

    Open SOPC builder or Qsys, whatever you use.

    Take note of the base address of epcs controller.

    Then select Nios processor and open its properties.

    Find the reset address box and make sure the address here matches the base address assigned to epcs controller

    Also make sure the exception vector is located at the beginning of onchip memory, usually with a 0x20 bytes offset (i.e. if your onchip ram address is 0x100000, exception vector should be 0x100020)

    Close Nios properties and regenerate the system

    Make sure that ecps pins are set as general purpose i/o in the Quartus configuration options, otherwise fpga will configure but Nios won't be able to access epcs.

    Now recompile the fpga design, bsp and Nios project.

    Good luck
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Cris72, thats what it was.

    Thanks a bunch!!

    For somebody that is newish to this stuff there is almost too much information that little details like this get missed.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Trouble is the GUI tools are a moving target! They also hide some stuff that you really need to know if you are intending building some bespoke system rather than showing you can follow the recipe book for the examples.

    Last time I tried to use the GUI stuff (to test some custom instructions) I had to remove the initialisers for a 12k internal memory block because the linker had appended the data to the code segment (8k tightly coupled) and included code to copy it to the required address. Clearly this won't work!

    In this case I just removed the initialiser since it wasn't needed for the testing I was doing.

    One way to find out what the tool chain has actually generated is by running 'objdump -p prog' and 'objdump -h prog' on the built program file. The first is the program sections - ie information for the loader, the second the actual sections that make up the program. Any version of 'objdump' will understand those tables, doesn't have to be the nios2 version.