Place a static library in specified memory region and mapped to the absolute memory ad

[Egolt.1]

I have an STM32 CubeIDE project.
I want to place a static library in an absolute memory address in the upper part of the internal flash while the application code will be placed at the beginning of the flash.
But the content of the library is allocated under the text region with the application code

I did this in the linker script:

 

 

 

MEMORY
{
ROM (rx) : ORIGIN = 0x08000000, LENGTH = 244K
LIB_region (rx) : ORIGIN = 0x0803D000, LENGTH = 4K
RAM1 (xrw) : ORIGIN = 0x20000000, LENGTH = 32K
RAM2 (xrw) : ORIGIN = 0x20009000, LENGTH = 28K
}
...
my_lib_section :
{
*(libTestLib.a)
} > LIB_region

 

 

 

[Pavel A.]

> I did this in the linker script

Not good enough. Please check the GNU link user manual how to specify source files/modules for a section (or ask chatgpt to help).

[Tesla DeLorean]

Why?

Your approach is probably not a good one. Would perhaps do better keeping the library in it's own project, with some method to export entry points if you're looking to reuse it, or share it amongst multiple applications. Some linkers could use this approach, and use a definition file to pass entry points. Better perhaps would be dynamic linking, but that obviously is more complicated, and would require the application to be able to fix-up itself on-the-fly depending on what library version it encountered.

The current setup is more geared to a monolithic application, which cherry picks the routines and dependencies it needs.

Likely going to need to become a Linker Script Wizard, directing the library and sub-objects into specific places, perhaps doing this in multi-pass fashion, or writing other scripts to process .MAP files, etc, and building a custom linker script so you don't need to do it by hand. Perhaps a thorough review of "Assemblers, Compilers, Linkers and Loaders" or similar college level texts.

[Egolt.1]

Because by doing so I can FOTA the main app without the need to send the lib part as well (The lib content is packed into a lib not for using in other multiple application but to save time and air time in the FOTA) and for that the lib should always be stored on a predefine absolute address so when a new app is sent by FOTA it will continue to work with that static lib.

The lib IS on a separate project but I need to link it with the app for the project to work, no?

I can set each routine manually to be placed in this section (as you said "cherry picks") but there is a lot of function that need to get into the lib and it is HAL and other code that I'm bring in and I don't want to mess with that source.

 

[Tesla DeLorean]

The general problem I see is that the HAL and compiler libraries are very fluid. Typically when you ROM library code you generate a definition file that lists the function entry points, and you feed that to your linker, and it then binds to those functions instead of the library code it might otherwise pull from .LIB / .A files. The ROM you want to kitchen-sink the content, big stuff like crypto, hashing, EC, CRC, etc which has large tables, and can be readily abstracted. Floating point would be another, and whatever common initialization of the CPU, system and pins that the app doesn't have to do-over.

Best to have this stuff in a loader on the STM32 parts, living at the front, and put the app deeper into FLASH. The loader can then recover failed up dates and validate the firmware image.

For FOTA have you considered compression or delta-patching ?

[Pavel A.]

>  so I can FOTA the main app without the need to send the lib part as well 

Yes, this is understandable. Your trick with the link script may even work (when done correctly). But consider what if slight change in compiler optimization or LTCG affects the static library part? At least you'll have to verify after every build that the 'static' part has not changed. At most, it will take a separate project for the static part, with some "export table" for the main app project, like @Tesla DeLorean suggests. Would be quite a lot of work, of course.

[hrosh.1]

test this script my_lib_section : { KEEP(*(.text.add)) } > LIB_region