--- Quote Start ---
originally posted by mir@Sep 10 2006, 02:19 AM
today,
the function attributes must be used in the prototype only, not in the function declaration itself:
extern void foobar (void) __attribute__ ((section ("bar")));
did you consider this?
mike
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=18187)</div> --- Quote End ---
Yes, that is how I set it up. The compile will fail otherwise. Here's what my map looks like
onchip_memory_main @ 0x10000
onchip_memory_int_code_s2 @ 0x20000
onchip_memory_int_data_s2 @ 0x40000
There is an appendage of "_s2" because these blocks are shared with another processor and therefore use the second port of a dual-port RAM. And here's how I defined my variables and functions.
volatile int value_in __attribute__ ((section(".onchip_memory_int_data_s2")));
void test() __attribute__ ((section(".onchip_memory_int_code_s2")));
void test()
{
puts("got here...\n\n");
};
If I check the hex files for that memory, the last two are full of zeros as well.
The assembly code is correctly assembled. When I try to execute the test function, it just lands in a patch of zeros @ 20000. My code in main() is correctly manipulating variables declared @ 40000.
What is mind-boggling to me is that the ELF file looks completely legit. Here's a dump.
Program Header:
LOAD off 0x000000b4 vaddr 0x00010000 paddr 0x00010000 align 2**0
filesz 0x00001980 memsz 0x00001980 flags r-x
LOAD off 0x00001a34 vaddr 0x00011980 paddr 0x00011980 align 2**0
filesz 0x0000055c memsz 0x00000670 flags rw-
LOAD off 0x00001f90 vaddr 0x00020000 paddr 0x00011ff0 align 2**0
filesz 0x00000048 memsz 0x00000048 flags r-x
LOAD off 0x00001fd8 vaddr 0x00040000 paddr 0x00012038 align 2**0
filesz 0x00000008 memsz 0x00000008 flags rw-
Sections:
Idx Name Size VMA LMA File off Algn
6 .onchip_memory_main 00000000 00011ff0 00011ff0 00001fe0 2**0
CONTENTS
7 .onchip_memory_int_code_s1 00000000 00020000 00020000 00001fe0 2**0
CONTENTS
8 .onchip_memory_int_code_s2 00000048 00020000 00011ff0 00001f90 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
9 .onchip_memory_int_data_s1 00000000 00040000 00040000 00001fe0 2**0
CONTENTS
10 .onchip_memory_int_data_s2 00000008 00040000 00012038 00001fd8 2**2
CONTENTS, ALLOC, LOAD, DATA
As far as I can tell, those load commands at the beginning are legit, and for some reason, they are completely ignored by the debugger. The debugger map looks fine as well. The only possible clue is that the "_s1" section is showing up here. s1 is connected to the other processor, so I don't know why that is showing.
Here's what the debugger is actually doing - only loading the first RAM device.
Using cable "USB-Blaster ", device 1, instance 0x01
Processor is already paused
Reading System ID at address 0x00002280: verified
Initializing CPU cache (if present)
OK
Downloading 00010000 ( 0%)
Downloading 00011FF0 (98%)
Downloaded 8KB in 0.1s
Verifying 00010000 ( 0%)
Verifying 00011FF0 (98%)
Verified OK
Leaving target processor paused
I think the next thing I might try is to delete the second processor and remove the dual-ports from the RAM and see if that clears things up. I don't know where to go from there since I think I really need to use the dual-port for my dual-proc design for the best performance.
Honored Contributor
