How do I enable link section overlap

[abyrvalg]

So your boot code calls the loader part for each data chunk? Then you need to place the boot data in the same RAM "view" as loader (and app’s data in the other overlaid view). But you have plenty of RAM to fit the SPI flash reading and MCU flash writing and run the entire update process from RAM w/o calling flash code. Your FLASH_BOOT area containing both parts of the updater is just 32K.

> multiple build configs, do you mean stuff like Debug versus Release?
Yes, those can be used to do much more than just changing the -O flag. You can i.e. create Boot and App configs, set different .ld files for each one in linker settings, exclude files not needed for this particular build flavor in each one and build two truly independent binaries from a single project (so you don’t need to hunt for boot dependencies drifted to the app part).

[peter-h]

"So your boot code calls the loader part for each data chunk? "

No; I jump to it and it never returns (it reboots).

It is working fine. I never found out how to overlay the loader with BSS etc but the loader is now in the top 4k of RAM which is where the main stack (8k) is when the product is running normally, so no RAM is lost and the issue has gone away.

Obviously I had to set SP elsewhere (to the top of CCM in this case) upon entry to the loader. Had a bit of fun with that, as you can see from the comments

Code: [Select]

// This is the entry point for when this module ends up in RAM.
// Should be the first thing here.
void loader_entry(void)
{

// Set SP to top of CCM. This is not where the KDE general stack is normally but it doesn't matter because
// the loader always reboots at the end.
// This asm code cannot be used if the function contains any stack based variables because they will have been
// allocated already and now we lose them!

asm volatile ("ldr sp, = 0x10010000 \n");

real_loader();

// never get here
for (;;);
}
In the running product, the CCM is used for the FreeRTOS workspace - all 64k of it.
 

[Doctorandus_P]

The book "Beginning STM32" from Warren Gay has a chapter about using overlays for STM32 and GCC.

Beginning STM32: Developing with FreeRTOS, libopencm3 and GCC
Warren Gay

ISBN-13 (pbk): 978-1-4842-3623-9     
ISBN-13 (electronic): 978-1-4842-3624-6

https://doi.org/10.1007/978-1-4842-3624-6
Library of Congress Control Number: 2018945101

[peter-h]

Thanks for the tip I bought the book and have been working through it. The overlay stuff is on page 156 onwards.

However it is pretty opaque - as indeed I suspected it would be. The syntax is weird and I am not going to spend time trying to unravel it since I have now bypassed the problem. But as I suspected the solution lies in the use of the keyword OVERLAY, and you need to thus declare all overlapping regions; there isn't a single keyword which tells the linker to just ignore the overlap of one particular section with some other one(s).

I think this topic is not well known because few people are using overlays today. It was a big thing in the old days, with e.g. the Z180 offering 64k addressing with a simple MMU giving you 1MB physical addressing, and compilers (we used IAR back then) having a "large model" mode where you had typically 60k of code+data and the last 4k was mapped to some address in a 1MB ROM, via an 8 bit overlay value. You had to make sure each C function fitted into this 4k (usually doable) but a 4k overlay could contain any number of small functions. Each function call consisted of loading the 8 bit overlay value into the register and then calling the function by its 16 bit address, so there was a bit of overhead but otherwise it was pretty transparent and a great productivity tool. Maybe some ARM users are doing overlays but it's not obvious when, other than if e.g. wanting to address a few GB.