Forum Discussion

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

Download of Nios II elf in Eclipse to UFM failing

Hi.

I have a Nios II project that was previously storing and executing the application in the OCRAM, and now am switching it to store the application in UFM and load it to the OCRAM at start up using the Altera memcpy based Boot Copier.

I have followed AN-730 and am implementing Option 2 with Dual Compressed Images.

I have made the changes in Qsys (see the attached image). UFM and OCRAM are both connected to the Nios instruction and data avalon-mm bus so that it can execute the Boot Copier on reset and then execute the program from OCRAM. The UFM sectors in the on-chip flash are both set to 'Read and write' in Qsys.

https://alteraforum.com/forum/attachment.php?attachmentid=13814&stc=1

I've also updated the bsp settings.

I have a Nios II application that I can confirm runs (uart interface working etc) when I follow these steps (from AN-730):

- Build in Eclipse

- make target mem_init_generate

- Use the Quartus "Convert Programming File" prompt to combine the memory initialization output with my hw config .sof to make a .pof.

- Program via the quartus_pgm.

What I cannot do however is program the elf to the Nios from eclipse. The Nios target is identified with the correct system ID and timestamp but I get an error during the elf verification: 


Using cable "USB-Blaster ", device 1, instance 0x00
Processor is already paused
Initializing CPU cache (if present)
OK
Downloaded 57KB in 0.9s (63.3KB/s)
Verifying 00C00000 (99%)
Verify failed between address 0xC00000 and 0xC0001F
Leaving target processor paused

Has anyone else had an issue getting this configuration to work with Eclipse?

Regards

2 Replies

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

    I've not used that method/flow before and I'm assuming that the UFM is at 0xc00000 (can't really see the attached diagram...sorry...). If that is the case there is no way that the IDE will be able to populate (download code to) that UFM. You'd have to program the UFM separately (from a HEX file that gets pulled in during QII compilation or via some sort of "flash programmer").

    This limitation of the IDE is not just with UFM, but with any (most?) non-volatile and/or flash memories in general. It's analogous to loading/running code out of EPROM/EEPROM. Debug IDEs typically don't support this or require a different "flash/'prom" programming flow to get the code loaded. To debug the code once it's been loaded, there's usually an option to connect to running process.

    Hope that helps!

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

    Thanks for your reply.

    Yes the UFM is at base address 0x00c00000, sorry I thought the diagram might have come out clearer.

    I was thinking that the debug connection would be capable of downloading to UFM, similar to programming the flash of non-FPGA MCU. It appears that is not the case though, at least without using another tool.

    And yes, connecting to a running target does work, I can debug that way.

    I'll figure out a workaround for my development need. It's good to know that this is the behaviour I should be expecting though, I've been scratching my head a bit wondering what I had done wrong.

    Thanks