2021-07-14 03:07 PM
Where might I find the information to do something like this ? Need to make good use of flash space and would like to keep one of the 16K sectors for updatable calibration data.
I would think this would be one solely in the linker script but evidently the programming wants to put everything into one contiguous length of flash.
I only see examples of a single flash memory definition when searching for such a concept.
I have done this before but with IAR.
2021-07-14 04:54 PM
AFAIK there's no magical tool for this, you need to manually assign functions or constant data to one of the discontinuous sections (probably the smaller one).
OTOH, the GNU linker is open source, you are absolutely free to modify it to do this automagically. Or write a better one from scratch, for that matter.
Or just bite the pill and simply waste the first 16kB to contain only the vector table and startup stub.
JW
2021-07-14 06:42 PM
I've looked for the solution to this before and came up empty. It doesn't appear that GCC LD is built to do this.
2021-07-14 07:29 PM
Thanks guys. The other guy actually using the CubeIDE (I am using IAR) says that as far as he can tell, it is actually the compiler that is making this diffiult.
We were both looking at the linker script and it would appear that different sections of code (WHY do they call it ".TEXT" anyway ??) can only be grouped into one part for each application and can't be separated. I find it hard to believe but I haven't seen anything other than that either. But I'm not nearly as wise to the ways of GCC as you guys or my co-hort, Jim.
I would think that this would be taken care of in the linker and script... I haven't seen how the original linker and linker script and the different sections memory assignments are generated. Isn't GCC some kind of two or 3 pass compiler ? Sounds like that might make some sense in this regard.
The assembly listing might elucidate some information on this. I would think this would be a standard compiler feature but maybe not all that important ?
2021-07-14 08:17 PM
I may have just found a clue in the LD Linker manual...
In part....
The special linker variable dot `.' always contains the current output location counter. Since the . always refers to a location in an output section, it must always appear in an expression within a SECTIONS command. The . symbol may appear anywhere that an ordinary symbol is allowed in an expression, but its assignments have a side effect. Assigning a value to the . symbol will cause the location counter to be moved. This may be used to create holes in the output section. The location counter may never be moved backwards.
SECTIONS
{
output :
{
file1(.text)
. = . + 1000;
file2(.text)
. += 1000;
file3(.text)
} = 0x1234;
}
In the previous example, the ‘.text’ section from ‘file1’ is located at the beginning of the output section ‘output’. It is followed by a 1000 byte gap. Then the ‘.text’ section from ‘file2’ appears, also with a 1000 byte gap following before the ‘.text’ section from ‘file3’. The notation ‘= 0x12345678’ specifies what data to write in the gaps
Well, I guess that says it. If one can't place a gap in one of these "files", then it can't be easily done except MAYBE in the assembler to divide one file into two memory areas so that code execution stops in one place in memory and starts again in another area so many bytes farther up.
2021-07-14 08:32 PM
You should be able to create holes/voids via the named MEMORY areas, say VECTORS, VOID,FLASH
Where you send particular sections/segments, objects and symbols can get more involved.
The programmatic approach might be to write a script to post-process a .MAP file and have it do a reasonable fit of the working set. This could be aided by using __attribute__ sections in the same way as the vector table is corralled up-front. And as Jan suggests grouping the vectors, startup, and initialization code, along with perhaps some tables to unpack the statics like the Arduino/GNU ports do
2021-07-14 11:07 PM
Thank you C1 !
😀