Forum Discussion

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

Not enough memory + ISS Problems?

OK, I have one or two problems.

One, in our Nios 2 design, we have used all of the M4K memory blocks so we can't add in the JTAG debug module. This means I can't download code from the IDE (or the command line I assume.) Is there a way to download code to the Nios 2 without having the JTAG Debug Module? I am going to build a modifed Nios 2 version with the EPCS controller removed (I don't need it if I'm using the IDE right?) and see if that works. Is there going to be a problem with the reset address being in RAM? What does the IDE do at reset?

Two, when trying to run the ISS with the same design, I get the following message:

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

Error! : Unable to load memory block at address 0x80020 from ELF file Debug/soft_keys.elf

Fatal Error! : Memory map is not consistent with memory image file - check that file &#39;Debug/soft_keys.elf&#39; is compiled and linked for system &#39;D:\workspace\doleksy\MC\mc\FPGA\Soft_Keys_2\LOCAL_NIOS.ptf&#39;[/b]

--- Quote End ---

Has anyone seen this? I am assuming that this has to do with not having debug support. Could the ISS be smart enough to know that I can&#39;t debug the hardware so it won&#39;t let be dug in the simulator either? I doubt it. I must be missing something.

Thanks for any help.

10 Replies

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

    UPDATE:

    I&#39;ve rebuilt the Nios 2 without the EPCS controller and now I get the following message when trying to debug with the ISS:

    <div class='quotetop'>QUOTE </div>

    --- Quote Start ---

    Error! : Unable to load memory block at address 0x80000 from ELF file Debug/soft_keys.elf

    Fatal Error! : Memory map is not consistent with memory image file - check that file &#39;Debug/soft_keys.elf&#39; is compiled and linked for system &#39;D:\workspace\doleksy\MC\mc\FPGA\Soft_Keys_2_Debug\LOCAL_NIOS.ptf&#39;[/b]

    --- Quote End ---

    This is the same as with the EPCS except the address it is trying to load code at is 0x80000 instead of 0x80020.

    When I try to debug with the actual hardware, it downloads the code and then continually resets. The first two lines of my main are: 

    printf("HELP ME!!!\n");
printf("========================================================================\n\n");

    I have breakpoints on these two lines and on the next line. None of the breakpoints get triggered. I know that there are some issues with using printf in a multi-threaded application, but the OS (MicroC/OS-II) hasn&#39;t started yet.

    Any ideas? Thanks ahead of time.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    22 years ago

    It sounds like you are in a bit of a corner in regards to the amount of memory you have available on chip.

    If you are using onchip memory for your code, then a recompile in quartus will quickly swap in your new code into your sof (without a full recompile) and you can redownload your sof to update your code. You are then limited to printf for debug.

    It is possible to build/download/run without an OCI core and without updating your sof, but unless you are running from flash and can burn some code into it, the solution will take more onchip memory than the OCI core does. Also once you make this choice you are operating in a much more primitive mode and you will have fewer tools and have to manage more issues yourself.

    To download code without the OCI core you must use the "Legacy sdk" (check the Legacy sdk support box on the More cpu_x settings tab).

    If you are running from external flash then you will want to burn the monitor into flash and run it after crt0. You will also not be able to debug with the IDE. Unless you port the gdb stub to Nios II you&#39;re debug method with actual hardware will be limited to printf.

    Once germs is executing on the CPU you can use the nios-run command to talk to it and download new code.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    22 years ago

    for Legacy usage, you must use the legacy components too.

    There&#39;s a doc on this in the Nios doc folder (it&#39;s an app note).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    22 years ago

    I guess what I really want to do at this point is debug on a system with no non-volatile memory. Is this even possible? I have made a Nios 2 design without the EPCS component so I can fit the debug module on it. This seems to almost work (see above posts).

    I just ported another of my boards over to Nios 2. This board have enough memory for the EPCS and debug components. But it fails everytime I try to debug with the following message:

    <div class='quotetop'>QUOTE </div>

    --- Quote Start ---

    The execution of program is suspended because of error.

    Cannot access memory at address 0x0[/b]

    --- Quote End ---

    I thought that I read somewhere that the IDE wouldn&#39;t try to run the code in the EPCS. Am I totally off here?

    So, can someone tell me what settings I need to debug a Nios 2 with an EPCS device. I eventually want to load the EPCS with my code but for now I just want the IDE to download my code into RAM and run it from there. Again, let me know if I am totally off base with what I want.

    Oh, by the way, if I try to debug with the ISS with this second board I get the same message as before:

    <div class='quotetop'>QUOTE </div>

    --- Quote Start ---

    Error! : Unable to load memory block at address 0x80020 from ELF file Debug/left_edit.elf

    Fatal Error! : Memory map is not consistent with memory image file - check that file &#39;Debug/left_edit.elf&#39; is compiled and linked for system &#39;D:\workspace\doleksy\MC\mc\FPGA\Edit_Control_Left_2\LOCAL_NIOS.ptf&#39;[/b]

    --- Quote End ---

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

    I have also seen the "unable to access memory etc" error while trying to debug on NiosI. I believe this happens whenever the code you have downloaded tries to access (or set a breakpoint) at an address that is not defined as R/W memory in your elf symbol table. For the ISS, it shouldnt really care since its all virtual memory anyway, but I think there has to be a way to re-define or add memory regions, either via the debugger console, or by loading additional symbol tables that overlay the map. I have not figured out how to do this myself so maybe this is all wishful thinking. Any GDB gurus out there?

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

    Do a google search on the difference between hardware breakpoints and software breakpoints -- this should shed some light on the issue. Debugging out of NV memory requires use of HW breakpoints. We include 2 HW breakpoints as part of the FS2 debug core that is supplied with Nios II.

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

    OK, maybe I&#39;m not making myself clear. For my design, the final product will boot out of the EPCS. BUt, while I am developing the software, I obviously don&#39;t want to have to flash the EPCS everytime I make a change. All I want to do is run the code in RAM. Is there no way to do this?

    For the Altera folks, exactly how do I need to setup my design so that I can use the debugger? Obviously I can&#39;t have an EPCS as the reset address. Nor can I have the SDRAM as the reset address. Where should the reset address be?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    22 years ago

    From one of the engineers...

    I hope this helps.

    1. we have to ask the ISS person about the ISS error. that isn&#39;t covered here.

    2... here it is.

    This is a matter of setting up his project correctly.

    Set the reset address as the EPCS device. But -- he does not want the EPCS to be his "target memory" (the area that gcc compiles his elf for. System library -> Properties -> System Library -> Linker Script). He wants that to be set to a volatile memory like SDRAM or on-chip RAM or something.

    When the reset address is the EPCS device, the incredibly-clever IDE will produce both an elf that&#39;s targeted towards the volatile memory (RAM), and a .flash file for the EPCS that contains both a bootloader and the elf.

    In normal in-the-field operation, the CPU will reset to the EPCS device. Upon reset, the bootloader code in the EPCS device will copy the elf file from the EPCS into whatever memory that elf is compiled for, then the CPU will jump to that memory and run the elf as normal.

    While debugging/running from the IDE, the IDE will not bother with the .flash file for the EPCS at all. It directly loads the elf file into volatile memory, sets the PC to _start, and runs user code from there. The reset address does not play into what PC the CPU begins at while debugging.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    22 years ago

    Kerri,

    First of all, thank you very much for the reply. Now, prior to reading your last post I had made some changes to the syslib to raise the debug level. After reading your post, I started the debug going and lo and behold, it worked. So, I think there may be a problem with the IDE recognizing when the syslib needs to be rebuilt. Because I didn&#39;t change the reset address. In fact, I didn&#39;t change the hardware configuration at all.

    So, again thanks. It all seems to be working now. Now on to my EPCS flashing problems...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    22 years ago

    the elf loader message comes up if the ISS fails to load up data from the elf file into the system when initialising. This usually occurs because the memory map as defined in the elf file doesn&#39;t match the ptf memory map, possibly because the elf file wasn&#39;t built for the ptf file in use. The other possibility may be that you&#39;re attempting to load data into a peripheral that isn&#39;t modelled by the ISS.

    Check out what peripheral it is, that lives at the address at which the elf loader fails, and check if that peripheral is supported by the ISS. In the IDE, when running the program with the ISS, there will be a list of warning messages for each of the peripherals in the system which are not supported by the ISS. If the peripheral living at the failing address is on that list, then you won&#39;t be able to write data to it. As a workaround, what you can do is go into the ptf file to the module causing a problem, and add the

    iss_model_name= "altera_memory";

    at the top module level. This will have the effect of the ISS simulating that peripheral as a block of RAM instead, thus allowing the elf loader to proceed.

    If this doesn&#39;t fix your problem, then it may well be a bug...