Forum Discussion

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

Problem debugging after bootloader loades

I have an Arria II GX device with an EPCS device attached. On this EPCS device I'm storing both the configuration and the application for NIOS. I'm able to use the NIOS default bootloader in the EPCS controller to copy the application to my external SRAM and start executing. This is all works fine. My issue is how can I make it possible to debug (NIOS) on the same FPGA build? The reset vector is pointing to the EPCS controller and I guess the NIOS IDE has problems writing to it since it is a ROM. I did try to hack the controller and made the internal memory a SINGLE_PORT but I'm seeing the same problem. Is there an easy way to do this without having to rebuild the FPGA? The message I'm getting is:

Downloading 00022000 ( 0%)

Downloading 00200000 ( 0%)

Downloaded 58KB in 0.9s (64.4KB/s)

Verifying 00022000 ( 0%)

Verify failed between address 0x22000 and 0x2201F

Leaving target processor paused

Device: Arria II GX

Version: Quartus and NIOS 9.1 sp2

Thanks

Boris

10 Replies

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

    I am also working with Arria, but i can not to work with it. I can not do the thins, that are working great in your project.I can not put both configuration and NIOS program to EPCS memory. How are you doing ot?

    In addition i have same problem as you.I can not debug NIOS program from FPGA?

    Have you solved this problem?

    Can you explain/give me your solution?

    Thank you,Slava.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    I never found a solution from Altera that worked out of the box for me. We actually ended up writing a custom boot loader that copied the NIOS application from the EPCS flash and put it in the external SRAM. The boot loader was placed in an internal ram (not rom) and therefore you can debug the application just like normal since the reset vector can be overwritten by the debugger.

    You will have to create the boot loader as a new application and make sure that all the linker sections are pointing to the internal memory. Once you have built your boot loader convert it to .hex file using the elf2hex utility. Rebuild the FPGA with the .hex file as your internal memory initialization file.

    The tricky thing in all this is to debug the boot loader. We struggled a bit with that.

    Hope this helped

    /Boris
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Debugging a nios boot loader is easy!

    Try booting a StareCore DSP through the HDI16 fifo ...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    When debugging a Nios application, the debugger does not need to update the code at the actual reset vector. After the debugger downloads your code it just sets the program counter to the start of your code. You just need to make sure your BSP is configured to not place any initialization code at the reset vector (make sure Advanced -> hal.linker -> allow_code_at_reset is off).

    To debug a boot loader you either need to place it in RAM or enable hardware breakpoints in your Nios configuration.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    You only need to add data access to the internal memory block that holds the bootloader code. This is probably needed anyway!

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

    Only adding a data connection to the memory with the boot loader is not always enough. If the memory is configured as ROM, you also need to make sure hardware breakpoints are enabled in your Nios config as you cannot set a software breakpoint in ROM. I think breakpoints are also used behind the scenes when single stepping.

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

    Thank you for your input Kevin. Changing the BSP settings is what I was looking for.

    - Boris
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Can you elaborate on how you solved this problem (schematic,SOPC,pin planner,IDE settings,etc....)?

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

    I added a small (8k will be more than enough) onchip RAM in SOPC builder and set the boot vector to the onchip memory.

    Then I created a small NIOS application that have all the sections in the newly created onchip memory that would copy the content in my EPCS flash to my external SRAM. After that I would jump to the start address in the external memory. This is the boot loader. I then converted the .elf file from the boot loader to a hex file using the elf2hex utility. Used the hex file as the initialization file for my onchip memory. Rebuild the FPGA.

    Then I created my real application for the NIOS. I set the reset vector to the internal memory and all the rest of the sections in the linker script to external SRAM. Debug this application as normal. Once you are happy convert the elf file to the format that the boot loader will read and make it a hex file. Program this hex file into the EPCS flash using the Quartus programmer tool.

    We actually made the boot loader read elf files directly. This wastes a bit of space in the EPCS flash but we had plenty of room. It copies memory section by section to the external SRAM.

    Hopefully this clarified some.