Multitasking of separately compiled programs in different flash sectors

3 separately compiled programs in different flash sectors of an MCU,
lets say the first one main code within Freertos scheduler and task creates,
the other 2 ones are app1 and app2, and they have different RAM partitions in the same MCU,
so the Flash has 3 partitions and the RAM has 3 partitions
the app1 and app2 and also main code are all separately compiled standalone programs for that MCU like in a regular bootloader example.
So could you please recommend me a way, to handle those scheduler. I guess it maybe static allocation with function pointers with that app flash start addresses and real stack partitions in Ram defined in linker file ? thanks in advance…

below you can see some definitions and snippets that i have tried but couldn’t what i aim;

The big problem you are going to run into is that these “separate apps” are not going to be able to use any FreeRTOS resources, as if they try, you will end up with two copies of FreeRTOS trying to run at the same time in the system. This means that you MUST enable round robin scheduling and make all these “separate apps” run at priority 0, or you will block the idle task.

Second, they must have been compiled for there “stack” to be at the address you have provided, and not be using that for their local ram.

You also need to make sure that none of the apps will try to share some bit of hardware with another app, since you have (easy) way to provide interlocks on that usage.

Also, the “startup” code for those apps must not reset the hardware used by FreeRTOS (this is basically a specific case of the above, but a piece that might not be though of).

Dear Richard, thank you for your kind interest and reply. I am not well experienced in FreeRTOS, this job will be my entry point and i have to do it anyway with all restrictions you have told, which are acceptable for me.

  • For the first issue, how can i set the scheduler for round robin and beyond that should i also make those “separate apps” run at priority-0 anyway?

  • When you say “local ram”, do you mean "seperate apps"s .bss and .data sections? or main code’s own static RAM? because i have already partiated the RAM in 3 pieces accordingly main code and those seperate apps.

  • for third issue, I will make those apps completely to use different peripheral units for example timer2 for first app and timer 3 for second app.

  • and for the last issue, i didn’t use systick timer for those seperate apps i have used accordingly timer2 and timer3 as their timebase source and;
    i have also deleted -SysTick, SVC and PendSV- handlers in those apps’ <core/interrupt.c> files. Should i do anything else to make them not to reset the hardware that FreeRTOS uses.

and finally is this checklist enough for a bare minimum scenerio that i have faced or would you add more to make a list for other critical points?

Please kindly note that again; the main code which is bootlader like, is the only code compiled with FreeRTOS in, the other “seperate apps” app1 and app2 are standalone minimum executable codes with hardware inits (like in a common bootloader example).

and if you don’t have time for those clarifications ,please just write further readings, keywords and references. Best regards…

For the first, you need to make sure that

configUSE_PREEMPTION is defined to 1 (which is the default)
configUSE_TIME_SLICING is also defined to 1 (which is NOT the default)

PREEMPTION allows switching away from a task at points other than a system call, which is needed since your tasks won’t make system calls.

TIME_SLICING allows switching away just because a system tick happened, otherwise switching only occurs if a higher priority task gets woken (or this task yields or blocks).

For the “local ram” is the ram assigned to each task. The space you allocate for your stack needs to be memory not allocated for its “data” (the .bss or .init data for file local or globals in the program).

The third issue needs to worry about sharing that might not be as obvious, watch out for things like the interrupt controller.

The last issue is you need to look at the system library startup code to make sure it doesn’t automatically touch some things that you don’t want touched after the real startup happened. Sometimes it will do things like automatically setup the system clock, assuming the system was just reset and working off a default setting. It might also manipulate memory/cache controllers that you don’t want changed. Placing “self-contained” applications inside other applications often needs digging into the assumptions that are built into an application.

I am not sure if these are an exhaustive list of things to watch out for, but the first things that come to mind that are apt to be quick road blocks (that might also hide and only cause problems later).

Are you looking for something similar to what I described here - Binary partitioning - #3 by aggarg

Also, what is your motivation for doing that?

the motivation that i have, is that i am new on OS’es and only have bootloader experience that can jump between multiple binaries so i am trying to push my understanding further with this scenerio; thus i can get into OS basics like loader, bsp, kernel and context switching.

your shared explanation is almost what i look for, could you also share some implementation code if i DM you as well ? thank you so much…

One thing to remember is that FreeRTOS isn’t an “OS” in the sense of Windows or Linux, as it isn’t something that runs other programs, but is a support library to run IN a given program, to provide it with a capability.