Problem with avr-objcopy. Section not copied to hex file

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
I am having a hard time with avr-objcopy for the last few days.
The requirement of my app is to have a global, initialized array of bytes, positioned at a specific address in the SRAM. To do this, I declared the array as follows:

unsigned char array_in_sram[] __attribute__ ((section (".custom_segment"))) = {0x80,0x83,0x86,0x89,0x8c,0x8f,0x92,0x95,0x98,0x9c,0x9f, ........};

and told the linker to link this segment at address=0x800100 and the data segment at address=0x800600:

avr-gcc.exe"  -mmcu=atmega644pa -Wl,-section-start=.custom_segment=0x800100 -Wl,-section-start=.data=0x800600 -Wl,-Map=MyProg.map -o MyProg.elf  MyProg.o

Now I'm at the point where everything works in the debugger the listing and map files looks fine. To transfer the code to the device I generate an Intel HEX file with the avr-objcopy command:

avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature  "MyProg.elf" "MyProg.hex"

Here comes the problem: the generated file doesn't contain the array variable. I've tried to mess with the -j and -R parameters with no luck.

I know I'm missing something. Hope you know what it is.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

at a specific address in the SRAM

Why on earth would you require this - the only reason I can think of is to share data between a bootloader and an app but you don't need fixed addresses for that - just some mechanism to pass a pointer between the two.

Anyway the only way that initialised variables in .data get their initial values copied to RAM is because the CRT contains a loop to do this. It only does this for .data though - you will need to hand craft a loop to do the same for your named section. Probably put this in .init5 so it occurs after the .data and .bss loops in .init4

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Why on earth would you require this - the only reason I can think of...

Well, I'm curious about the need as well.

But if I want a really fast circular buffer, I'd put it on a mod 256 boundary and make the size a power of two. So now you have one more reason.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the quick reply to all of you.

The app need to implement a Direct Digital Synthesis and for that i need the address to be aligned at mod 256 boundary and at specific addres, thus the algorithm can be very small(8 cycles) and I need it in SRAM because it must be modifiable.

Thanks again and be happy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

muisei wrote:
The app need to implement a Direct Digital Synthesis and for that i need the address to be aligned at mod 256 boundary and at specific addres,
So the question is again: why the specific address?
The alignment alone can be done without a custom section at a specific address.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
So the question is again: why the specific address?

Just for optimization reasons.
Quote:
The alignment alone can be done without a custom section at a specific address

By "specific address" do you mean it is 256byte aligned or there is a way to manually set it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

muisei wrote:
By "specific address" do you mean it is 256byte aligned or there is a way to manually set it?
What I mean is that the alignment can be done without the section-fiddling, by defining (and initializing) the variable with the alignment in a simple assembler file. Then you have the data at a 256 byte boundary, but not at a specific address. It will be at 0x0100, or 0x0200, or 0x0300, or ... wherever the linker has put it.

So my question is:

Quote:
i need the address to be aligned at mod 256 boundary and at specific addres
Do you really have (as written) the need for the alignment AND the specific address? Or do you think you have the need for the specific address BECAUSE OF the alignment?

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Then you have the data at a 256 byte boundary, but not at a specific address. It will be at 0x0100, or 0x0200, or 0x0300, or ... wherever the linker has put it.

Side note: These are AVR >>micro<< controllers. Most models won't have many choices in the matter. If any at all. ;)

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

.

Stealing Proteus doesn't make you an engineer.

Last Edited: Thu. Mar 17, 2011 - 07:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GCC has supports for aligning variables trough the "align" attribute. No need from the separate assembler file nor any other funky stuff.

Quote:
__attribute__((align(256))) in the var declaration.

Quote:
Do you really have (as written) the need for the alignment AND the specific address? Or do you think you have the need for the specific address BECAUSE OF the alignment?

Due to the internals of the algorithms I'm using, positioning the data at specific address would save me a couple of cycles inside a loops. Imagine I need four of those buffers sticked one after another and there is a cycle accessing every value of every buffer consequently. The order of the buffers is of a vital role. For now they are declared inside one C file and the linker is linking them one after another in the order I declared them, but in the future their declarations will be in separate files and thus they will not be linked in the order I need thus inside the loop I will have to check for the end of the buffer and calculate the address of the next one.