Forum Discussion

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

Unable to boot from on-chip RAM

Hi,

I am using QuartusII version 11.1. I have designed a custom board with Cyclone IV E FPGA, EPCS16 configuration device, character LCD and some other ICs. I could successfully build a Qsys system, develop a code for displaying to LCD in NiosII SBT for Eclipse, and see the output after downloading the elf through JTAG interface. The Qsys system consists of bare minimum - NiosII /e core, on-chip RAM, LCD controller, JTAG UART, etc. There is no external memory.

Now I want to initialize the on-chip RAM with the hex software image, and program the pof file into EPCS device, so that on power-up the FPGA gets configured and starts running the code from on-chip RAM. I am not able to achieve this simple goal in spite of so much effort. I have ensured the following:

1. I had followed the steps provided in the Embedded Design Handbook, namely the HAL BSP settings for booting and running from FPGA memory, ie, Table 2-6. I have set hal.linker.allow_code_at_reset to 1, and others to 0.

2. I have also set all the linker sections pointing to onchip_mem. reset, .text, .bss, etc all are pointing to onchip_mem.

3. I used the make for mem_init_generate to generate the hex file. It had used the correct base address, ie the base address of onchip_mem in Qsys. Here is the command run by SBT for generating the hex file:

elf2hex cnb1.elf 0x00010000 0x0001f9ff --width=32

--little-endian-mem --create-lanes=0 mem_init/first_nios2_system_onchip_mem.hex

4. mem_init_generate had generated the hex file and even a qip file, in addition to some other files. I copied the hex and qip files to QuartusII project directory, and added the qip file to my project. I performed a full compilation. The map report where the hex file was picked up is as follows:

+-------------------------------------------------------------------------------------------------------------+

; Parameter Settings for User Entity Instance: first_nios2_system:u0|first_nios2_system_onchip_mem:onchip_mem ;

+----------------+--------------------------------------+-----------------------------------------------------+

; Parameter Name ; Value ; Type ;

+----------------+--------------------------------------+-----------------------------------------------------+

; INIT_FILE ; ../first_nios2_system_onchip_mem.hex ; String ;

+----------------+--------------------------------------+-----------------------------------------------------+

It seems that the hex file has been picked up, though the "../" makes me believe that it is going one hierarchy up. Anyway when I burn this pof to EPCS, and later power-on, I don't see anything happening. Some display is supposed to be printed in the LCD screen.

5. I even went back to Qsys and set the memory initialization hex file to the one generated by NiosII SBT. Then I generated the system, and came back to QuartusII and recompiled the whole design. I can see in the map report that the correct hex file was picked up. Here is the information.

+------------------------------------------------------------------------------------------------------------------+

; Parameter Settings for User Entity Instance: first_nios2_system:u0|first_nios2_system_onchip_mem:onchip_mem ;

+----------------+----------------------------------------------------------------------------------------+--------+

; Parameter Name ; Value ; Type ;

+----------------+----------------------------------------------------------------------------------------+--------+

; INIT_FILE ; D:/Nios_designs/nios2_sys/software/cnb1/mem_init/first_nios2_system_onchip_mem.hex.hex ; String ;

+----------------+----------------------------------------------------------------------------------------+--------+

Even this pof file seems to have no effect on the boot process. I don't see anything at all :-(

6. To make sure that JTAG UART was not creating any issue, I even removed it from Qsys, and performed the whole procedure again. This too had no effect on the LCD display. It just doesn't seem to work :-(

7. I even programmed the sof file (containing the hex software image as well) directly to FPGA. This also was fruitless :-(

Can someone please help me out with this simple problem.

thanks and regards,

rajesh

10 Replies

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

    I would check that the elf file has everything in the expected places.

    Run objdump -h foo.elf, objdump -P foo.elf and objdump -d foo.elf.

    -h list the elf sectoon headers.

    -P is the program headers (they are normally used by a program loader).

    -d is the disassembly.

    You should have a small piece of code at the reset vector that does little more than jump to (probably) alt_main.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    I have just discovered that the on-chip memory was successfully configured by the hex software image. The only problem was that NiosII was not running from the reset location. This is how I found it out. I programmed the EPCS with a hardware/software image where the code is meant to display "I am LCD" to the LCD display. Upon power-up I don't see this display. I then changed the code to display "I am GCD". I then downloaded the elf through JTAG. I can see that during this process NiosII executed the existing software code! I could see the original software output "I am LCD". During this process SBT downloaded the new software image to the on-chip RAM. And after some time I could see the output of the new code "I am GCD". Does this give any hint. I feel that somehow NiosII is not able to start-off from the beginning of on-chip RAM, upon power-up.

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

    Hi dsl,

    Thank you for the response.

    I ran the checks on the elf. I get the following output for disassembly view:

    mem_init/first_nios2_system_onchip_mem.hex: file format ihex

    objdump: Can't disassemble for architecture UNKNOWN!

    Does this give you any hint. I am not able to understand this.

    regards,

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

    Hi dsl,

    I am sorry. I ran it on the hex file. Here is the output of -h after running on the elf file:

    cnb1.elf: file format elf32-little

    Sections:

    Idx Name Size VMA LMA File off Algn

    0 .entry 00000020 00010000 00010000 00001000 2**5

    CONTENTS, ALLOC, LOAD, READONLY, CODE

    1 .exceptions 00000194 00010020 00010020 00001020 2**2

    CONTENTS, ALLOC, LOAD, READONLY, CODE

    2 .text 00003630 000101b4 000101b4 000011b4 2**2

    CONTENTS, ALLOC, LOAD, READONLY, CODE

    3 .rodata 000003e8 000137e4 000137e4 000047e4 2**2

    CONTENTS, ALLOC, LOAD, READONLY, DATA

    4 .rwdata 00000380 00013bcc 00013bcc 00004bcc 2**2

    CONTENTS, ALLOC, LOAD, DATA

    5 .bss 00000160 00013f4c 00013f4c 00004f4c 2**2

    ALLOC

    I have not shown the remaining outputs. The base address of on-chip RAM is 0x00010000. The .entry section is pointing to this location as can be seen in this output.

    The output of -p is here:

    Program Header:

    LOAD off 0x00001000 vaddr 0x00010000 paddr 0x00010000 align 2**12

    filesz 0x00000020 memsz 0x00000020 flags r-x

    LOAD off 0x00001020 vaddr 0x00010020 paddr 0x00010020 align 2**12

    filesz 0x00003f2c memsz 0x0000408c flags rwx

    The -d produces the same error:

    objdump: Can't disassemble for architecture UNKNOWN!

    Can you get some idea here.

    regards,

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

    The NiosII refuses to run from the .entry location upon power-up and configuration. It is only when the SBT tries to download a new elf through JTAG that the NiosII tries running the existing code, and then later on is made to run the new updated code. I have enabled Altera logging. Here is output from this:

    [crt0.S] Inst & Data Cache Initialized.

    [crt0.S] Setting up stack and global pointers.

    [crt0.S] Clearing BSS

    [crt0.S] Calling alt_main.

    [alt_main.c] Entering alt_main, calling alt_irq_init.

    [alt_main.c] Done alt_irq_init, calling alt_os_init.

    [alt_main.c] Done OS Init, calling alt_sem_create.

    [alt_main.c] Calling alt_sys_init.

    [alt_main.c] Done alt_sys_init.

    [alt_main.c] Redirecting IO.

    [alt_main.c] Calling main.

    Hello from NiosII

    [alt_exit.c] Entering _exit() function.

    [alt_exit.c] Exit code from main was 0.

    [alt_exit.c] Calling ALT_OS_STOP().

    [alt_exit.c] Calling ALT_SIM_HALT().

    [alt_exit.c] Spinning forever.

    [crt0.S] Inst & Data Cache Initialized.

    [crt0.S] Setting up stack and global pointers.

    [crt0.S] Clearing BSS

    [crt0.S] Calling alt_main.

    [alt_main.c] Entering alt_main, calling alt_irq_init.

    [alt_main.c] Done alt_irq_init, calling alt_os_init.

    [alt_main.c] Done OS Init, calling alt_sem_create.

    [alt_main.c] Calling alt_sys_init.

    [alt_main.c] Done alt_sys_init.

    [alt_main.c] Redirecting IO.

    [alt_main.c] Calling main.

    Hello from NiosII

    [alt_exit.c] Entering _exit() function.

    [alt_exit.c] Exit code from main was 0.

    [alt_exit.c] Calling ALT_OS_STOP().

    [alt_exit.c] Calling ALT_SIM_HALT().

    [alt_exit.c] Spinning forever.

    As can be seen, the first crt0.S was started only after SBT tried to download a new elf through JTAG. The existing code was executed upto exit(). Following this after some time the new updated code was run to completion.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    I've seen the jtag run the old code like that before - NFI why it does that.

    We actually load code over PCIe.

    I'd check the nios cpu config and check the address of the reset vector. It might point to the wrong place.

    To run 'objdump -d' you need to find the copy of objdump installed by altera (likely to have "nios" in the filename).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    I have checked the reset vector of the CPU. It is pointed correctly to the start of onchip_mem.

    I am doubting the clk_reset signal connected in Qsys. The documentation for clk_0 says that "Clock output interfaces cannot have reset signals". I can't understand what this is trying to say. Does this mean that externally applied reset, which is made to pass through the clock block doesn't propagate to the modules in Qsys. This is what I observe in practise. NiosII doesn't jump to the reset location when I press the reset button on the board, but the JTAG interface is able to reset the processor.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Try building without the jtag debug module at all.

    It might be holding the cpu in reset.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Hurray! This worked for me!

    I seem to remember to have performed this before as well but withouth any result. It has worked now. Maybe I had made some mistake before.

    The JTAG UART block was somehow preventing NiosII from getting reset. Thank you dsl for the support.

    During the update of memory initialization file from QuartusII, I get the following warning:

    Warning (113015): Width of data items in "first_nios2_system_onchip_mem.hex" is greater than the memory width. Wrapping data items to subsequent addresses.

    This is even though the onchip_mem is specified as 32 bits in Qsys, and the hex file was generated by SBT using the make of mem_init_generate. There SBT used width of 32 bits. Why is it that I get this warning? But anyway it worked nicely for me.

    thanks and regards,

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

    Hi dsl,

    The problem was not with the JTAG module. The culprit was the cpu's jtag_debug_module_reset signal. I had connected it to the cpu's reset_n signal in Qsys. It was a loopback connection in addition to the clk_reset signal coming to the cpu. When I removed the connection from jtag_debug_module_reset, I no longer faced any issue, even if the JTAG UART block is present in the system.