avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] a symbol for end of program memory used?


From: Erik Christiansen
Subject: Re: [avr-gcc-list] a symbol for end of program memory used?
Date: Fri, 30 Apr 2010 18:34:02 +1000
User-agent: Mutt/1.5.15+20070412 (2007-04-11)

On Thu, Apr 29, 2010 at 07:31:55AM -0700, Dave Hylands wrote:
> On Thu, Apr 29, 2010 at 6:18 AM, Erik Christiansen wrote:

Incidentally, that was "23:18:32 +1000" at my keyboard. At 6:18 AM, it
would have been well past my bedtime. Your MUA is converting to UTC?

> > But the .eeprom output section specifies an LMA coincident with
> > __data_load_end. To be safe, I'd place something like the following
> > after the end of the .eeprom output section in the linker script:
> >
> >   __vacant_flash = __data_load_end + SIZEOF(.eeprom);
> >
> >   or with same effect:
> >
> >   __vacant_flash = LOADADDR(.eeprom) + SIZEOF(.eeprom);
> 
> Why include the .eeprom section? This is an image of what's to be
> included in the EEPROM and normally isn't written to the flash.

Well, while it's there mostly for tools like avrdude, we can load
.eeprom to flash, to provide a run-time "Restore Defaults" option.

I've just done an "objdump -h" on my nearest avr object file, and
there's no "ALLOC, LOAD" for .eeprom, so it's not loaded to flash by
default, and that executable would be OK without the suggested
protection.

However, the linker script does have:
*******

  .eeprom  : AT (ADDR (.text) + SIZEOF (.text) + SIZEOF (.data))
  {

which _does_ set a load address of the first free flash byte. The trap is set.
Anyone choosing to alter the section's "ALLOC, LOAD" status, to store EEPROM
default values in flash, _will_ need something like my suggestion, because
__data_load_end won't cut it any more.

> I guess you could use it as a "default", so whether you include it or
> not in the vacant_flash calculaton should depend on whether you
> include it in the .hex file to you use to load to flash.

Yes, the original protection will leave SIZEOF(.eeprom) flash bytes
unused, if .eeprom is not deliberately loaded to flash. Since objcopy
can change section flags after compilation, there would be no merit in
modifying the vacant_flash calculaton on whether .eeprom is loadable at
that time, even if a mechanism existed. However, we can do this in the
linker script:

   __vacant_flash = DEFINED (__eeprom_in_flash) ? __data_load_end +
                    SIZEOF(.eeprom) : __data_load_end ;

   /* ld should't care whether it's one line or wrapped. */


Now there will by default be no wasted flash bytes, because
__vacant_flash = __data_load_end , but when we use on the commandline:

ld --defsym __eeprom_in_flash=1    # Or in gcc-friendly syntax:

avr-gcc ... -D eeprom_in_flash

then our linker script will obediently shuffle __vacant_flash up to make
room for .eeprom.

Will that do?

Erik

-- 
If at first you don't succeed, try again.
Then Quit. No use being a damn fool about it.              - W.C. Fields




reply via email to

[Prev in Thread] Current Thread [Next in Thread]