Nios Debugger does not load all memory segments

Altera_Forum · ‎09-11-2006

I've been asked to summarize my post (http://forum.niosforum.com/forum/index.php?showtopic=4750) of a similar title where I kinda figure out what is going on with the Nios debugger not acting the way I thought it was supposed to.

Basically, I set up two additional memory blocks for code and data for a total of three blocks, like this

onchip_memory_main @ 0x10000
onchip_memory_int_code @ 0x20000
onchip_memory_int_data @ 0x40000

Using the system library builder, I told Nios to use onchip_memory_main for all sections (.text, .rodata, .rwdata, the heap, and the stack). However, I manually placed some of the code into the other blocks using the __attribute__ modifier.

volatile int value_in __attribute__ ((section(".onchip_memory_int_data")));
void test() __attribute__ ((section(".onchip_memory_int_code")));
void test()
{
puts("got here...\n\n");
};

So the problem is that after compiling and then launching the debugger, you will find that the debugger did not place your code or static data into the later two sections. What happened is that they have been appended to the end of the first section (in my case, onchip_memory_main). That's because it appears the linker is caught up in this mode of making a ROM image of some sort (this appears to be the default behavior of the Altera Generated Makefile Builder script).

I've not been able to turn off this behavior, unfortunately. But the clue to a workaround comes from what you would have to do if your code was truly running from a ROM of some sort. Right after boot, you would have to populate all the RAM memory segments. The Nios generated library will do this for all segments you told it about. But for the ones you didn't, you have to run some relocation code yourself.

#include <sys/alt_load.h>
int main(void)
{
...
    ALT_LOAD_SECTION_BY_NAME(onchip_memory_int_code);
    ALT_LOAD_SECTION_BY_NAME(onchip_memory_int_data);
...
}

This worked for me. The downside is that it wastes memory in the first memory block.

For more details about this process, read my previous post (http://forum.niosforum.com/forum/index.php?showtopic=4750), maybe in reverse order from the bottom. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/biggrin.gif

Altera_Forum · ‎09-11-2006

Hi,

Thanks very much for your summary...

But it will be much more valuable if you figure out the root reason in detail and then point out how to workaround and why.

A completed summary is difficult but is very significative...

Thanks again,

David

Altera_Forum · ‎09-11-2006

--- Quote Start ---

originally posted by david_cai@Sep 10 2006, 09:46 PM

but it will be much more valuable if you figure out the root reason in detail

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=18203)

--- quote end ---

--- Quote End ---

Well, that's the real problem here, of course. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/wink.gif And I have no clue about it, really. I am hoping someone reading this can tell me what to do.

As far as I can tell, the problem exists in the file "generated.x", which appears to be made by "Altera Generated Makefile Builder". Unfortunately, this builder does not seem to be configurable at all. It only allows one unselectable project type of "Nios II Executable".

Somewhere in the Project Properties, there needs to be a single checkbox that says, "Build for ROM image". Either that, or the debugger itself needs to deal with this "virtual address" that's in the ELF image and allow you to fake the situation of all RAM sections being loaded directly.

Of course, if I built my own make files and linker files, it would be easy to avoid this problem. But I don't want to do this, as it defeats the entire point of tightly coupled development with SOPC builder.

Altera_Forum · ‎09-11-2006

Try using a custom linker script.