Object files that are "too big"

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

I recently made some changes to some code and after attempting to program my device, AVR Studio reports that "The contents of the objectfile exceeds teh maximum program memory of the device."

During a build, however, the following is reported by the build tools:

AVR Memory Usage
----------------
Device: atmega324p

Program:   23000 bytes (70.2% Full)
(.text + .data + .bootloader)

Data:       1553 bytes (75.8% Full)
(.data + .bss + .noinit)

I have a couple of custom defined memory sections that sit in the uppermost part of memory (0x7D00 to the end) and don't receive any complaints about code being too big to fit in those sections.

I currently use -O3 optimization as I need the speed for my application.

I've looked at the .map file to find where the memory usage might be overstepping the bounds of the device, but don't see anything right off. Perhaps I'm reading it wrong or looking in the wrong section of the file?

Thanks in advance to anyone who can shed some light on this.

Apologies if this should have been in the AVR Studio forum.

Edit: Compiling with -Os reduces program size to 20392 bytes, but AVR Studio still refuses to program the object file.

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

You do have the correct AVR selected when you program, right? (Not the same setting as the setting telling the compiler what AVR you are building for.) What do you get if you hit Read Signature in the programming dialogue?(My apologies if this is "below your level".)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Mon. Jun 23, 2008 - 09:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you post the .map file?

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

Johan: Yes, the correct part is selected. I managed to avoid the obvious mistakes this time (or did I?, see below), but still a good suggestion; I've had build/program errors caused by such things before.

I did, however, manage to figure out the problem, or at least a workaround.

I had also changed where I defined my custom memory sections from the "Custom Options" area of the Project's options, to the "Memory Settings" area. A quick perusal of the Makefile generated by AVR studio showed that the linker options had been changed from the addresses that I had specified to something else; for example where I put in 0x7F50, the Makefile had 0xFEA0. So apparently AVR studio expects word addresses, outputs byte addresses, and the linker is ignorant of the device type. Thus I didn't notice the problem until I tried to program my device.

I don't know if this is a known issue or the way AVR Studio was intended to operate. Perhaps this merits a post in the AVR Studio forum?

Thanks for the quick replies.

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

Just looking at the build output will show the linker option passed that defines the section address. I suspect they went with word addresses there (avr studio flash memory settings) because the datasheets show word addresses for bootloader sections (just a guess).

I don't know if this is a problem in your case or not(I suspect not, since you would get an 'overlap' error), but there seems to be a linker bug that causes the bss section to have an LMA that is different from the VMA (should be the same), which has the effect of 'reserving' text section space for the bss section which is not needed (similar to the data section, but in this case with no actual data being 'populated' into that space). If that bss LMA address range conflicts with a text section you defined, you get an 'overlap' which produces the complaints.

When you look at the lss file, you can see if the bss section LMA and VMA are different (started in winavr20071221).

more info and a simple fix-
https://www.avrfreaks.net/index.p...

and a simple test to cause the overlap-

#include 
//.test section 0x100(word address)
//-Wl,-section-start=.test=0x200
unsigned char var[0x200];
void func(void) __attribute__((section(".test")));
void func(void){
    PORTB=0;
}
int main(){}
//error output-
//section .test [00000100 -> 00000103] overlaps section .bss [000000c2 -> 000002c1]
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What changes have you done? Maybe you have now defined the fuse bits in your sourcecode (fuse.h)? If yes, then you can't program the hex files into your AVR anymore. Select the *.elf file instead.

Regards
Sebastian