RE: Constant at fixed address

[Henrique Coser <henrique.coser@xxxxxxxxxx>]

David,

Sorry, I was not clear enough about my system.

The Atmel , sam3s4b that I use has more memmory than that.
I have limited the flash since this part of code is a boot loader that is separeted of main application.
During firmware upgrade only the main application is erased and the boot loader  remains in the memmory.

Boot loader area must be lower than 5KB (0x1400) to keep space enough for main application.
So If I change the script as you propoused, I will not have space enough for boot loader.

The section is not declared into the script, is declared as a linker parameter :

 -Wl,-section-start=.bootversion=0x00401000

I have already tried to make a "hole" in memmory.
Imagine that you have a splited flash, like if you have two memmory banks, how should I change the script to automatically distribute the code between these two "memmory banks"?

If I find a way to make this split , I can put the boot loader version in the middle.
What I wanted is something that can do this as easy as Keil does.
I know that Keil will make it and will work, but since is the trial version, I can not embed this solution using Keil.

Thank you very much for all attention that you gave.



Henrique Coser

Engenharia



TEX Equip.Eletronicos Ind.e Com.Ltda.

Fone: (+5511) 4591-2825

henrique.coser@xxxxxxxxxx<mailto:compras@xxxxxxxxxx>

MEDIR PARA MELHORAR!
________________________________
De: David Brown <david.brown@xxxxxxxxxxxx>
Enviado: 26 de fevereiro de 2022 15:57
Para: Henrique Coser <henrique.coser@xxxxxxxxxx>; Martin Sebor <msebor@xxxxxxxxx>; gcc-help@xxxxxxxxxxx <gcc-help@xxxxxxxxxxx>
Assunto: Re: Constant at fixed address

On 25/02/2022 22:37, Henrique Coser wrote:
> Martin and David,  thank you for your answers.
>
> Attached is the linker script that I use.
>
> In Keil, where I did the first version of the boot loader I can assure you that a constant value is placed and correctly filled when use __attribute__((at(0x0401000)))
> I don't know how they do this but they do!
>
> I would be grateful If you could help me editting this script.
>
> Thank you very much.
>
>

The length of your "rom" space in sam3s4b_flash.ld does not make much
sense.  I haven't used Atmel's SAM devices, but I'd be surprised to see
one with a little under 12 K flash.

The linker files you attached are not, I think, the ones you used when
you got the link error - they don't have any mention of the
".bootversion" section.  So all I can do is show a typical way to have
this set up in a linker file.



Your "rom" section starts with :

   .text :
    {
        . = ALIGN(4);
        _sfixed = .;
        KEEP(*(.vectors .vectors.*))
        *(.text .text.* .gnu.linkonce.t.*)
        ...
    } > rom

That will put the ".vectors" section(s) first, at the start of rom, then
everything after it.

What you need to have is the fixed sections, then everything that can be
freely allocated:

   .headers :
    {
        FILL(0xff)
        . = ALIGN(4);
        _sfixed = .;
        KEEP(*(.vectors .vectors.*))
        . = 0x1000;
        KEEP(*(.bootversion .bootversion.*))
    } > rom

   .text :
    {
        . = ALIGN(4);
        *(.text .text.* .gnu.linkonce.t.*)
        ...
    } > rom


Then the main ".text" and other flash sections get put after the
bootversion section, and you don't get an overlap.

This wastes the space between the vectors and the fixed .bootversion
section, but you could put other data there if you like (maybe some of
the arrays used for constructors or initialisation).  Don't bother
unless you are tight for space.