A solution came to mind on the way to work.  It takes several steps to
explain, but in summary what I did was use inline assembly code for the
particular constant instead of using just C.

First, I added a line to my compiler flags to cause them to generate the
assembly .lst file:

-Wa,-adhlns=$(subst $(suffix $<),.lst,$<) \

(tacked onto the CFLAGS definition).

Next, I did a make.  This created .lst files for everything.  The ones I
needed I kept, the others I deleted.

I edited those lst files to produce true ASM code.  I could have put
these into the makefile as assembly source, but I chose instead to embed
them into the appropriate .C files.

For instance, the declaration above

>   const unsigned char  ieee_mac[6] = {
>    0x00, 0x30, 0x86,  // Our IEEE OUI number
>    OUI_MINE,    // This product's code
>    0xFF, 0xFF};    // Assigned by chip burner

is now commented out, and the comparable assembly is inserted as a
series of C asm() statements as shown below:

//  const unsigned char  ieee_mac[6] = {
//    0x00, 0x30, 0x86,  // Our IEEE OUI number
//    OUI_MINE,    // This product's code
//    0xFF, 0xFF};    // Assigned by chip burner

asm ("  .global  ieee_mac");
asm ("  .section  .fixed");
asm ("ieee_mac:");
asm ("  .byte  0");
asm ("  .byte  48");
asm ("  .byte  -122");
asm ("  .byte  16");
asm ("  .byte  -1");
asm ("  .byte  -1");

Next, I had to update the linker file.  I did it by inserting the .fixed
section as the first one, then allowing it to work its regular stuff
from there.

MEMORY
{
  flash  : ORIGIN = 0x00100000, LENGTH = 0x3F000
  fixed  : ORIGIN = 0x0013F000, LENGTH = 0x1000
  ram  : ORIGIN = 0x00200000, LENGTH = 64K
}

_stack_end_ = 0x00200000 + 64K - 4;

SECTIONS
{
  . = 0x0013F000;
  .fixed :
  {
    _fixed_beg_ = .;
    *(.fixed)
    _fixed_end_ = .;
  } >fixed

  . = 0;
  startup : { *(.startup)} >flash
...

I hope this helps others.

Andy

Thanks for the reply, Martin.

> Just an additional suggestion: Did you check the gcc variable-attribute
> section (see gcc-manual)? The (inline-)assembler-code can be avoided by

At the time I did this, I had not found the attributes for variables
section yet.  Use of the attribute on the variable would have been much
more elegant.

> Remark on your linker-script: If you declare an extra MEMORY area for
> "fixed" the line . = 0x0013F000; should not be needed. Did you try to
> link without this line in the linker-script?

The reason for the separate section is because we will be putting a
bootloader into the same area eventually.  I do not want the possibility
of application code being in the same region - I would prefer to have
the linker tell me I ran out of memory first.

I appreciate all you've done with this work.  Your examples have been
very helpful in understanding how to approach solutions to problems in
several areas.

Andy

Martin,

I just implemented the code according to your example and it works fine.

The extra MEMORY line is to force a specific load address for the data.
It will be in a protected portion of memory shared with the bootloader.
I didn't see another way to force it to the exact address I wanted.

Thanks.

Andy