Use of a library from multiple applications

[MOtto.2]

Hi, i was thinking about placing some libraries in a reserved area on the flash and access them from two or more applications. For instatnce a bootloader and the corresponding application. I would like to update them, that's way don't like to incoporate them in the bootloader. How could that be achieved?

Thanks in advance

[KnarfB]

There is a nice video series How to Create a Super Simple Bootloader, Part 5: Sharing the API has it: https://youtu.be/fVwGCUzLxt4

hth

KnarfB

[MOtto.2]

Thanks, in this video they make use of functionpointers and share them betwwen apps. OK. But who is responsible of initializing the peripherals? And when bootloader sets up the peripherals and later it jumps to the app and it itself does some initializing too, doesn't they get confused. Is there any thing to be considered. I thaugth when jumping from bl to an app you should deinitialize everything and the app will reinitialze his part later.

[waclawek.jan]

> But who is responsible of initializing the peripherals?

Well, those all are questions you should answer yourself...

> I thaugth when jumping from bl to an app you should deinitialize everything and the app will reinitialze his part later.

That's conceptually the simplest thing to do, as you can treat the separate portions of code being completely independent. But then, as you want to have a significant common portion, you may as well decide to have a common initialization of certain or all peripherals. The decision will heavily depend on the particular details of what you want to achieve.

At the end of the day, you are in full control of all the resources - peripherals, external peripherals, memories, etc. - don't you? I'd say, using "libraries" decreases the level of control and increases chances of failure, but this is your project.

JW

[waclawek.jan]

Maybe an analogy helps (although analogies inevitably fail in the details): it might be a good idea to share a car with your wife/friend. Any arrangement which allows you to call common functions is analogous to giving copy of the car key to friend. But if you don't make up front an agreement on how do you schedule usage of the car, who and when fills it up with gas, who takes care of the maintenance, who pays ensurance etc., or you don't stick to that agreement rigorously, problems ensue, sometimes not immediately but bite later.

Sometimes it is simpler/better to get two - maybe smaller, cheaper - cars.

JW

[S.Ma]

To have a fixed code shared among application is like the BIOS of a PC.

Usually, it was in ROM. And to be universal, a SWI #ID (software interrupt with index table) is used to make the calling code "portable". On most STM32, non volatile memory reduce the interest of putting a library in memory.

[MOtto.2]

Yes, for some small libraries you can choose that approach, but what if you like to use bigger libs like a can stack or tcp/ip stack, i think you barley write your own. Also your end binary would be rather small as you get ride of the libraries included in that build. In case of a fw update you just give the changing part away rest remains the same.

Well i haven't try that. STM Cube gives the a possibility to write a static lib. Could you place all your libs in there and write a kind of de/init lib functions to be called from either bl or app1 app2 etc...? This static lib would be placed in a third part of the flash memory as bl and app takes there own part. And what about interrupts. When jumping between apps you have to relocate the vector table related to that app.

Any advice.

[waclawek.jan]

I don't think this is something people do often. Read, it's unlikely you'll get much first-hand-experience based information.

Maybe you should start small - write e.g. a UART-based bootloader, and try to write some simple applications which use the same UART - maybe just echo or something simple like controlling a LED.

JW

[Tesla DeLorean]

Back when doing ROMs using RealView, we could dump a lot of library code into the ROM, print/buffering, floating point, complex computations, as the memory was fast and a lot of the code was invariant and self-contained.

We'd take the .MAP file, using scripts to extract functions and entry points, edit it down a bit, and use it to create a definition file we could pass to the linker. The linker for the FLASH code could then bind against this, using the ROM routines rather than pulling from the C libraries.

With GNU/GCC you might be able to do this with Linker Script, or objects/libraries with absolute function addresses. Might take some effort. More complex now as people keep changing/updating tools as frequently as their underpants..

Newer versions of the HAL might work too, the ones where the call-backs are in the instance/structure rather than hard linked by name. Older versions, not so well thought out

A table with function entry points might also be workable.

For the STM32 might help to partition things so the loader does a lot of the pin, clock and hardware initialization, and then the app doesn't repeat that work.

[Piranha]

You are missing the main point of the bootloader - it must be immutable! That means it cannot rely on any code that can be updated. If that is not the case, then the bootloader is not reliable anymore. If you need to update the code, which updates the main firmware, you need a second level "bootloader" or I would call it an "updater". Basically it's the second application, the task of which is to update the main application.