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

Log in or register to post comments
Go To Last Post
10 posts / 0 new
Author
Message
muisei
muisei's picture
Level: New Member
Joined: Wed. Mar 16, 2011
Posts: 4 View posts
#1
Posted by muisei: Wed. Mar 16, 2011 - 03:30 PM
  • 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.

Tags:

Tools, Compilers and General Programming, ATmega64, ATmega644
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 104932 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Mar 16, 2011 - 04:28 PM
  • 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

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40559 View posts
Location: Wisconsin USA
Posted by theusch: Wed. Mar 16, 2011 - 04:55 PM
  • 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.

Top
muisei
muisei's picture
Level: New Member
Joined: Wed. Mar 16, 2011
Posts: 4 View posts
Posted by muisei: Wed. Mar 16, 2011 - 05:16 PM
  • 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.

Top
sternst
sternst's picture
Level: Raving Lunatic
Joined: Mon. Jul 23, 2001
Posts: 3499 View posts
Location: Rheine, Germany
Posted by sternst: Wed. Mar 16, 2011 - 05:49 PM
  • 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

Top
muisei
muisei's picture
Level: New Member
Joined: Wed. Mar 16, 2011
Posts: 4 View posts
Posted by muisei: Wed. Mar 16, 2011 - 06:57 PM
  • 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?

Top
sternst
sternst's picture
Level: Raving Lunatic
Joined: Mon. Jul 23, 2001
Posts: 3499 View posts
Location: Rheine, Germany
Posted by sternst: Wed. Mar 16, 2011 - 08:36 PM
  • 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

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40559 View posts
Location: Wisconsin USA
Posted by theusch: Wed. Mar 16, 2011 - 09:19 PM
  • 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.

Top
ArnoldB
ArnoldB's picture
Level: Raving Lunatic
Joined: Thu. Nov 29, 2007
Posts: 3185 View posts
Posted by ArnoldB: Wed. Mar 16, 2011 - 10:00 PM
  • 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
Top
muisei
muisei's picture
Level: New Member
Joined: Wed. Mar 16, 2011
Posts: 4 View posts
Posted by muisei: Wed. Mar 16, 2011 - 10:39 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.

Top